DaISy – Datacast Information System Group: Sotanorsu Customer: Digita Oy 7.4.2004 T-76.115 Final...
-
Upload
august-george -
Category
Documents
-
view
222 -
download
0
Transcript of DaISy – Datacast Information System Group: Sotanorsu Customer: Digita Oy 7.4.2004 T-76.115 Final...
DaISy – Datacast Information System
Group: SotanorsuCustomer: Digita Oy
7.4.2004
T-76.115 Final Demonstration and Review
2
T-76.115 Final demonstrationT-76.115 Final demonstration
Agenda
Product presentation (5 min) Demonstration (15 min) Project evaluation (15 min) Questions and comments (5 min)
3
T-76.115 Final demonstrationT-76.115 Final demonstration
DaISy – Datacast Information System
Future: DigiTVInternet (DVB-T)
• Upload pictures and movies
• Create slide shows
• Attach PDA content
• Manage displaying content based on location
• View location based slide shows and movies (e.g. advertisements)
• Browse internet and extra content using PDA
CoDSyDB
Bluetooth CoDSy
GPS
CoMSy DB
HTTP
WWW
CoMSy
4
T-76.115 Final demonstrationT-76.115 Final demonstration
Product Demonstration
5
T-76.115 Final demonstrationT-76.115 Final demonstration
Project Evaluation
6
T-76.115 Final demonstrationT-76.115 Final demonstration
Team Sotanorsu
Aleksi Ahtiainen (AA) – Project management 2004, Quality Control, Documentation, Development
Jussi Koponen (JK) – Architecture, Development
Kirsi Louhisuo (KL) – Requirement engineering, Configuration management, Development
Simo Neuvonen (SN) – Project management 2003, Infrastructure, Development
Esa Puttonen (EP) – User Interface, Development
Eiri Valanto (EVa) – Risk management, Development
Essi Vehmersalo (EVe) – Testing, Peer Testing, Development
7
T-76.115 Final demonstrationT-76.115 Final demonstration
Project Progress [1/4]
In total: 1412 hours Documentation, meetings and project
management took 52% of total work Many hours of programming still in DE
phase (minor improvements and unexpected bugs)
0
50
100
150
200
250
300
350
PP I1 I2 I3 DE
Hours by worktype
Documentation
Testing
Programming
Design
Comp. Maintenance
Lectures
Studying
Proj.Management
Meetings
Meetings22 %
Design8 %
Programming26 %
Testing6 %
Documentation12 %
Comp. Maintenance
4 %
Studying3 %
Lectures1 %
Proj.Management18 %
8
T-76.115 Final demonstrationT-76.115 Final demonstration
Project Progress [2/4]PP Iteration – Meetings and requirement
design Work practices documented Requirements specified and prioritized with the
customer Infrastructure built (TWiki collaboration
platform, mailing list, IRC channel) Problem: Bugs in Trapoli system -> Own hour
reporting practice using CVSI1 Iteration – Design and basic features Architecture designed 11 more requirements implemented and tested Problem: Bugzilla had no module division ->
Own bug reporting within Twiki Problem: Work hour estimates exceeded ->
Had to decrease hours from plans in following iterations
Problem: Some hardware was delayed -> Had to concentrate on other issues
0
10
20
30
40
50
60
AA EP EVa EVe JK KL SN
PP phase personal hours
PP planned
PP actual
0
10
20
30
40
50
60
AA EP EVa EVe JK KL SN
I1 phase personal hours
I1 planned
I1 actual
9
T-76.115 Final demonstrationT-76.115 Final demonstration
Project Progress [3/4]I2 Iteration – Programming Lot of programming More focus on demonstrational use in meeting room
-> DVB-T internet in moving vehicle dropped 17 more requirements implemented and tested Problem: Work hours underrun -> Had to increase
work share for some members in I3 and DE Problem: Unit testing not working as planned -> Did
code review and increased weight of system testing Problem: GPS module and DVB-T cards not
functioning -> Had to delay implementation Problem: Too heavy risk management practice ->
specified a lighter oneI3 Iteration – Concentrating on requirements for
final configuration 26 more requirements implemented and tested Group and customer thought more about final
demonstrational use: some new requirements specified and implemented for
easier demonstrational use visualization of moving vehicle (GPS) -> demo
preparation took time had to drop specification of large system issues
0
10
20
30
40
50
60
70
AA EP EVa EVe JK KL SN
I2 phase personal hours
I2 planned
I2 actual
0
10
20
30
40
50
60
70
AA EP EVa EVe JK KL SN
I3 phase personal hours
I3 planned
I3 actual
10
T-76.115 Final demonstrationT-76.115 Final demonstration
Project Progress [4/4]
DE Iteration – Finalization 6 more requirements implemented and tested Attainment of goals and project practices
analyzed with the customer and within the Sotanorsu team
Problem: Contract not signed, decided on postponing physical delivery to after easter -> easier to run final demonstrations. Customer has been able to test system through internet
Problem: More bugs found than expected, major problem in exception situation handling as well -> Some minor and trivial bug fixes after the preplanned final code freeze on Sun 28th March, major bugs well documented. The system was retested after these.
0
10
20
30
40
50
60
70
AA EP EVa EVe JK KL SN
DE phase personal hours
DE planned
DE actual
11
T-76.115 Final demonstrationT-76.115 Final demonstration
Goal attainment Out of the original 10 customer goals:
4 were reached: Using GPS information WWW interface for management Scalable architecture Easily extendable (some refactoring needed, though)
4 were dropped in I2: Use of DVB-T internet Well adapted for DVB-T internet use External internet connection on PDA Automatic content transfer (user triggered now in demonstration
environment) 2 low priority goals were not reached:
The system is not error-prone and can recover from errors The system is secure
12
T-76.115 Final demonstrationT-76.115 Final demonstration
Work share between team members
Project management: AA and SN managers, EVa and KL created demonstration content
Design: JK responsible for architecture design Programming: EP and JK did the most Documentation: AA did most of the project plan and reports, KL responsible for user
guide and requirements document AA: Did plenty of implementation work during the fall 2003, not as many hours left for
project management in the spring. Spent a lot of time managing the techinical aspects of the project in addition to secretarial management.
0
50
100
150
200
250
300
AA EP EVa EVe JK KL SN
Worktype share of team members
Documentation
Testing
Programming
Design
Comp. Mgmt
Lectures
Studying
Project mgmt
Meetings
13
T-76.115 Final demonstrationT-76.115 Final demonstration
Software size
Total: 103 requirements, of which 60 implemented
Line count is not very good estimation method, but:
Total: 9100 NCLOC, 4900 COM Would have been average size
on 2002-2003 course Well commented (1/3 of lines
in comments)
0
10
20
30
40
50
60
PP I1 I2 I3 DE
Number of requirements across iterations
High priority reqs
Implemented High priority reqs
Medium priority reqs
Implemented medium priority reqs
0
2000
4000
6000
8000
10000
12000
14000
16000
18000
PP I1 I2 I3 DE
Software size in lines of code
SQL code lines
JSP code lines
Java code lines
14
T-76.115 Final demonstrationT-76.115 Final demonstration
Quality assuranceRequirements and testcases
0
20
40
60
80
100
120
PP I1 I2 I3 DE
Implemented requirements
Testcases
0
10
20
30
40
50
60
70
PP I1 I2 I3 DE
Cumulative number of found bugs by severity
Blocker
Critical
Major
Minor
Trivial
0
5
10
15
20
25
30
Trivial Minor Major Critical Blocker
Total bugs by severity
Open
Closed
In addition: 182 code review issues, of which 156 fixed
remaining ones are related to bug below and also some non-prioritized unit test class issues
1 major bug remains in exception situation handling
Wasn’t noticed well enough until DE iteration code review. This second code review should have been done in I3 instead.
Not a problem in proof-of-concept demonstration environment
15
T-76.115 Final demonstrationT-76.115 Final demonstration
Evaluation of used practices Good at all other process related
issues instead of risk management Most critical about implementation
related practices. Speculation: Built-in perfectionism in every
technology-oriented computer science student?
Easy for coders to think that it is their fault, that even one bug remains in the software, although that might have originally been caused by some trouble in the process
Our use of practice
0,00 1,00 2,00 3,00 4,00 5,00
Unit testing
User interface planning
Risk management
Static methods
Assessment of architecture
Architectural planning
Bug management
Refactoring
System testing
Coding convention
Communication within the group
Use cases
Communication with the mentor
Meeting practices
Requirements prioritization
Team organization
Hour reporting
Project reviews
Scheduling
Requirement management
Communication with the customer
Version control
Iteration planning
Iterative development process
Documentation
16
T-76.115 Final demonstrationT-76.115 Final demonstration
Evaluation of used tools Good tools to keep in mind in the future:
CVS TWiki collaboration platform
Not so fun tools to work with: WWW user interface, but I guess in our place and time we just have to live with it…
17
T-76.115 Final demonstrationT-76.115 Final demonstration
Lessons learned Great introduction to iterative software development process It was very helpful to plan the work practices in the beginning of the project instead of just starting
to write code Good experience in making work estimates It takes a lot of work to both lead the people and manage the technical issues of the project in this
course’s setting
If only... If final code review had been done already in I3, no major problems would remain in the software The user interface and especially it’s architectural connection to the software should have been
planned better A person with more visual skills and enthusiasim would probably have gotten our final product
prettier Maybe a clearly a separate person being responsible for leading and managing technical details
would have made the process more efficient and taken some of the stress out of the project manager
A separate server at the customer premises would have made it possible for the customer to test software on site instead of over the network
Course feedback Couple surprise mentor visits per iteration to the team meetings, customer meetings and computer
classrooms might give mentors better inside information in the process. Progress reports and reviews are only the showcase
Arranging 4 demonstrations of the software, when it is not totally physically movable, takes a lot of effort. Maybe demonstrations at the actual production or development environment?
The calendar time of 7 months is long for this process and makes it very difficult and also more unrealistic to control. Maybe the course could be done in a single spring term?
Thank you for listening!
Questions?Answers?