NOTICE!

1. NOTICE! • 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 2003/2004). • 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!

2. Selected Topics in Software Engineering-Distributed Software Development

3. Course Builder Developer Team

4. Today • Project status and statistics • How it looks? • How it works? • How we got here • Demonstration

5. Project status and statistics

6. Project status / statistics • Financial plan • € 31500 estimated • Just over € 10 000 wasted • Recent milestones • M008 Completing business logic / design of GUI • M009 Integration / testing (W 03) • M010 Final delivery

7. Project status / statistics

8. Project status / statistics • Workload • Over 1200 working hours • Per team member – 150 • Real situation almost coresponds +/- 20 or less • Almost perfect work distribution?  • Lines of code • No mistakes and no fixing • ~2 200 per developer • Real • ~ 3500 per developer

9. Project status / statistics

10. Project status / statistics

11. Project status / statistics

12. How it looks

13. GUI ?

14. GUI

15. GUI • Header • global application menu – link to sections: user courses, user details, administration sections) • Pop up dialogs for editing propeties

16. GUI • Application body • Main content in the central part • Modules on the left/right

17. GUI – Course sections • My courses • List of user courses • Create new course • Course editor • Course details • Course syllabus (list of course objectives, topics, activities) • Add or edit course objectives, topics, activities, materials, resources… • Course reports • View or download • Syllabus, workload…

18. GUI – Admin parts • My details • user propeties (user name, login password, preffered language…) • System management (administrators only) • Default language, allow self registration… • User management (administrators only) • Create, delete users, change their details

19. How it works

20. Our Challenges in DSD • Communication • Following the same concepts by all teams • Proper assignment of tasks (Balanced Workload...) • Wise managements of available resources ( e.g Member’s Current skills & knowledge …) • Proper Architecture for DSD – According to the application (good componentization…)

21. How we managed… • Friendly team environment • Frequent communication (Email, NetMeeting, Skype and other instant messaging applications) • Constant availability  Fast debugging and fixing of problems • Following appropriate architecture • Specified points of work distribution and responsibilities (points of supervision…)

22. How things work … Structure: ----------------------------------------------------------- • GUI & Code Behind • Façade • Base Components • DBAccess • User Component • Course Data Component

24. Database Diagram

26. How we got here

27. How we got here? Requirement specification Design Project Plan GUI Data Base Analysis Facade Business logic We are HERE

28. Project plan • Purpose: • make the project path, milestones and rolls clear to follow • Distributed implications: • Distributed group means having members in the group with more variousskills and styles of work, and difficult things are to coordinate things in the right direction

29. Project plan • How we solved it? -We make our project plan and modify it as it follows the distributed project character and also it suitable all members in group -We break the project in small component base on our architecture -The Sweden group is responsible for the business logic, façade, and data base and the Zagreb group is responsible for the GUI and integrating the solution from façade to GUI • Keep distributed stuff in mind • Try to find best solution for all • Small components • The Sweden group - business logic, façade, and data base • Zagreb group - GUI and integration

30. Project plan • What’s our proposal solution for making the project plan in distributed projects? - Divide the work by split up the application in parts so that each group can work on their part and to define a clear interface so that the other group can follow that interface. In that way everyone can concentrate on their given task and by that spend the time most efficient and it would be less confusion internally.

31. Analysis • Purpose: • Getting information from the customer • Cleared the aspects of the project • Distributed implications: • Lack of face to face communication • Lack of speaking in mother language

32. Analysis • How we solved it? • We use lots of voice chat, chat, emails and less web cam • Whole group participates • One person responsible for continuously communicate with the customer and clear the costumer request for the group • What’s our proposal solution for doing the analysis in distributed projects? • Analysis need more communication effort, • two person from each group responsible for analyzing • communicate with customer face to face and clear all aspects of the project

33. Requirement specification • Purpose • Clear the requirements of the system • Distributed implications • Just like analysis problem is lack of face to face communication and also mother language

34. Requirement specification • How we solved it? • We use lots of voice chat, chat, emails and less web cam • Whole group participated • One person responsible for continuously communicate with thecustomer and validate the requirements • What’s our proposition for doing the requirement specification in distributed systems? • Have one person from each side responsible for communication with the customer locally

35. Design • Purpose • Modelling and designthe application/project. • Distributed implications : • Problems with explaining design in distributed environment • Possible errors

36. Design • How we solved it? • All members responsible for ideas, the Sweden group bacame directly responsible for design • 3 architectures proposed • 1 chosen when accepted by group • Checkin design simultaneously • We use lots of voice chat, chat, emails and less web cam • What’s our proposal solution for doing the designing in distributed systems? • Most important – good componentization • Making clear interface between the distributed design

37. Implementation • Top – down method (more or less) • Distributed implications: • Componentization Data Base Business logic GUI Facade

38. Implementation • How we solved it • Componentization • GUI modules • Business logic componentization • Facade to facilitate integration • What’s our proposal solution for doing the implementing in distributed systems? • Componentization • Have a middle component that facilitates integration • More componentization Data Base Business logic GUI Facade

39. Testing • Purpose • Testing the product if it satisfy the customer requirement, test the unit, system, • Distributed implications • One of the problems in a distributed project when it comes to testing and finding bugs, could be to point out exactly where and when in the code the bug appear.

40. Testing • How we solved it? • Testing started before development end.. • Step 1: checking the requirement specification with customer • Step 2: checking the design specification if it satisfied the requirement or if there is any incorrect design • Step 3: testing each unit by the author • Step 4: according to the course builder architecture, developing divided in four components: database, business logic, façade, GUI. This step of the testing plan is testing each component individually. • Step 5: testing integration each component with each other • Step 6: testing the first release of the application • Steps 7: testing the last versions of the system -

41. Testing

42. Demonstration

43. Live Demonstration .. Let’s hope not.. 

44. Questions