1. 1 PennDOT ATX Project Spring Semester EOSP Team Stalagmite: Dan Abramovich Jeff Ditillo Andrew Guletsky Oksana Schubert Alexey Stolpovskikh Dehua Zhang

2. 2 Agenda Introduction People –Adding a person to the team Process –Platform selection –Risks Technology –Prototypes –Architecture Summer Plans Software People Technology Processes

3. 3 Introduction Problem description –New solution for PennDOT on-line vehicle title and registration services Major stakeholders –PennDOT –ATX (our clients) –Participating companies Business drivers –Improve PennDOT ’ s business processes –Allow ATX to become PennDOT ’ s Business Partner

4. 4 Context Diagram

5. People5 People: Team Changes Different leadership style –Shared decision making  more individual decision making Lightweight process because of time constraints –Rediscovered risk-task centric approach Added a new team member  Changed team dynamics –More resources (+) –Communication overhead (-) –Previous MSE/Studio experience (+) –Good individual skills (+)

6. People6 People: Lessons Learned Individual skills become critical The role of a new comer should be clearly defined Imposes communication overhead Brooks Law holds only for already late projects

7. Process7 Process: Platform Selection Expectations –Put Management and (new) Methods material into practice => rational decision –Completed two evaluation phases, prepared for the third (and final) phase Reality –Poor task estimation: no firm due date –Push from Mentors –Vote => Java/J2EE/JBoss –Team became more focused

8. Process8 Platform Selection: Lessons Learned Strong experience needed for successful evaluation Ranking is extremely expensive –Requires extensive research of all candidate platforms –Time consuming:.NET/MQ prototype took 36 hours Rational decision making is feasible when: –Domain experts for all candidates are present –Minimal time constraints –Making the right choice is critical

9. Process9 Monitored/Mitigated Risks Communication delays with PennDOT Gatekeeper simulator ≠ real Gatekeeper Uncertainty with client application development Unknown capabilities of JBoss Knowledge transfer from departing team member

10. 10 Risk Mitigation: Prototypes Security –SSL, login module and custom security proxy (+) Entity bean performance with large records –No performance bottlenecks (+) –Transactional (lazy) replication on DB (-) JasperReports (open source) –Support for data sources (+) –Difficult to create report templates (-)

11. 11 Prototypes (cont’d) Gatekeeper simulator Miniature transaction processor –JMS and MDB communication with MQ (+) –Performance questions under stress (-) Entity bean PK auto-increment issue –JBoss 3.2.0 native support (+) –Need JDBC 3.x compatible driver (-)

12. 12 Prototypes: Lessons Learned Open source enforces self-sufficiency –No vendor support –Forces deep investigation (newsgroups, Google) –Prototype => cost effective analysis J2EE compliance does not tell the whole story –Security solution is JBoss proprietary Need to learn more J2EE technologies –Client system participation in transaction –Entity beans PK auto-increment issues

13. 13 Demo

14. Technology14 UML Analysis: Lessons Learned Strengths –Valuable insights learned for key use cases Weaknesses –Some use cases never got attention –No full traceability from use cases to architecture –UML is like religion Some believe it and others do not Most useful when there is full commitment –Full-time students are not familiar with RUP Change of Methods curriculum

15. Technology15 Architecture: Quality Attributes Security –Allow “good guys” to get in; keep “bad guys” out –Prevent client access to inappropriate information –Support user privileges Availability –Failover; recovery from errors Modifiability –Extend the system easily –Update transaction descriptions, op. codes and fees without code changes Performance –Provide reasonable user experience for many concurrent clients

16. Technology16 Deployment Views Key Decisions/Facts Requires minimum 2 computers –AppServer and DB servers combined –Requires at least 4 computes for high availability/performance Replicated DB exposes one virtual IP address Gatekeeper exposes one IP address –Replication and redundancy transparent to ATX

17. 17 Architecture: Deployment Diagram

18. Technology18 Logical View Key Decisions/Facts Separate Admin and Client interfaces Flexible location of Database layer –Either co-located with AppServer or separate server –Most data storage managed by AppServer container Secure channel between client and server –Role-based authentication and authorization Server blade requirements –Each needs WebSphere MQ client –Full state replication between blades Requirement for replicated file storage (MSCS)

19. 19 Architecture: Logical View

20. Technology20 Architecture: Lessons (NOT) Learned Did not identify the “message queue” architectural style –Not covered in Architecture class –No skills developed to easily adopt new architectural styles

21. 21 Summer: Schedule

22. 22 Summer: Development Process Individual development of work items –Quality through design/code reviews –Units correspond to architectural components Nightly builds and regression testing Quality monitoring and bug bashing days Periodic integration tests Test UI is a superset of Admin UI

23. 23 Summer: Anticipated Risks Untimely access to information and resources  schedule slips Schedule is based on guesstimates  may be unrealistic Only suboptimal choices available with free software

24. 24 Summer: Process Artifacts Project plan Test plan Configuration management plan Development plan Architecture description (UML, Visio and Word) Software requirement specification

25. 25 Q&A

26. 26 Additional Slides

27. 27 UML: Logical View

28. 28 Transaction Manager Package

29. 29 Gatekeeper Manager Package

30. 30 Transaction Sequence

31. 31 Transactions – Run Time View

32. 32 Administration – Run Time

33. 33 Reporting – Run Time