1. 12015-05-14 These materials are prepared only for the students enrolled in the course Distributed Software Development (DSD) at the Department of Computer Science and Engineering, University of Mälardalen, Västerås, Sweden and at the Faculty of Electrical Engineering and Computing, University of Zagreb, Croatia (year 2010/2011). For all other purposes, authors’ written permission is needed! The purpose of these materials is to help students in better understanding of lectures in DSD and not their replacement! NOTICE!

2. 22015-05-14 Distributed Software Development

3. 32015-05-14 Public Transportation System ”PTS” Omar T. Jaradat

4. Project Overview Development methodology Deliverables Communication Milestones Activity plan Financial plan Project risks 42015-05-14

5. PTS development methodology PTS will use Agile ”UP” methodology. Incremental release-based development. 52015-05-14

6. Why using AUP? AUP supports Incremental release- based development. The AUP applies agile techniques including: 1. Test driven development. 2. Agile Modeling Tool independence You can use any toolset that you want with the Agile UP. 62015-05-14

7. Deliverables PTS development process depends on three iterative releases In addition to the traditional planned deliverables PTS has three more. Releases V1.0, V2.0 and V3.0 72015-05-14

8. Deliverables (Cont.) 82015-05-14 ToOutput Planned week Promised week Late +/- Delivere d week Rem Steering Group & Customer Project plan document40 0 On Time Steering Group & Customer Requirements Definition document 40 0 On Time Steering Group & Customer Design Description document 41 N/A CustomerPTS First Release v1.044 N/A CustomerPTS First Release v2.046 N/A CustomerPTS First Release v3.048 N/A

9. Deliverables (Cont.) 92015-05-14 ToOutput Planned week Promised week Late +/- Delivered week Rem Steering Group & Customer Acceptance test plan 50 N/A Steering Group & Customer Test report 22N/A Steering Group & Customer Final Project Report, final versions of existing documents, other project- related documentation (as negotiated with the customer) 22N/A Steering Group & Customer Final product (installation, source code, etc.) 22N/A Customer (*) Final Report10 N/A

10. Communication strategy 102015-05-14

11. Milestones PTS has five main milestones: 1.Requirements analysis charts and diagrams - week 43 2.PTS First Release v1.0 – week 44 3.PTS First Release v2.0 – week 46 112015-05-14

12. Milestones (Cont.) 4. Evaluation Report “after creating prototype model” – week 46 5. PTS First Release v3.0 – week 48 6. System architecture and design structure – week 50 122015-05-14

13. Activity plan 132015-05-14 Activity W39w40w41w42w43w44w45w46w47w48w49w50w51 Project preparations Requirements analysis & definition Requirements Prototype Design System Architecture System Implementation Testing (Acceptance, Unit, Integration, V&V) Documentation System Delivery

14. Financial plan 142015-05-14 Activity Volume (days) CostRem. Project preparations ~10 Priceless Requirements analysis & definition ~10 Priceless Requirements Prototype ~8 Priceless Design System Architecture ~12 Priceless System Implementation ~43 Priceless Testing ~25 Priceless Documentation ~15 Priceless System Delivery ~5 Priceless

15. Project risks 152015-05-14 Possibility scenario RiskPreventive action High Umple language still new and the Occasional bugs are very possible. Stuck with some unsolvable bugs which will late the whole project workflow. Manual editing the generated code from Umple but after having permission from project sponsor. High Umple language still new and the missing or incomplete features is something expected. Changing the model design which can affect on the other parts and this requires redesign process. Design separated modules and units based in Object oriented modeling methodologies to avoid any unneeded affection. Low Bad Timeline estimation due to some unexpected technical or normal issues Exceeding the estimated timeline. Timeline should be reviewed weekly or at least every two weeks by the Project Manager and the Steering group.

16. Project risks (Cont.) 162015-05-14 Possibility scenario RiskPreventive action Medium The project team members feel that they can not communicate efficiently. Team is scattered Expand Communications Plan LowSVN troubles Losing the contents or bad subversion actions. Always have a backups and save all project relevant LowSickness absence One or more members get sick and quit the project for a while Increase the working hours for the rest team members to make up

17. Questions... 172015-05-14