1 / 16

Contents

Public Advice Traveling Help DSD Course – Project final Presentation School of Innovation, Design and Engineering Malardalen University Jan 15 th , 2008. Contents. Introduction Project final Presentation Team Members Project Analysis Development Model Milestones

Télécharger la présentation

Contents

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Public Advice Traveling HelpDSD Course – Project final PresentationSchool of Innovation, Design and Engineering Malardalen UniversityJan 15th, 2008

  2. Contents • Introduction • Project final Presentation • Team Members • Project Analysis • Development Model • Milestones • Architectural decisions • Risk Management • Effort Metrics • Financial Metrics • Communication • Requirement Compliance • Testing • Project Experiences • Score Approach • Demo

  3. Project Analysis – Development Model Requirement, Design and implementation were in parallel rather sequential. Individual working with short meetings. Responsibilities and roles Conclusion: Helped in multi tasking and proper initial planning Reorganized ourselves to long working under same roof. Faster problem solving Conclusion: Experienced better implementation phase RUP Agile 3

  4. Project Analysis - Milestones Conclusion • Most tasks were on time. • Implementation and testing were delayed by 1 week. • Prototype development should be complete before implementa- tion starts to avoid delay. 4

  5. Project Analysis – Architectural Decisions As a result of our research into requirements we were guided on how to make decisions as to our system architecture. • Software selection • L.A.M.P • GoogleMaps API • Project Architecture • User Interface Layer (UIL) • Business Object Layer (BOL) • Data Access Layer (DAL) 5

  6. Project Analysis - Risk Management • Time shortage • Competence in technology • Key resource leaving the team • Miscommunication • Design Flaw • Database server crash • SVN server crash • Choose of wrong technology • Installation problem • Server unavailability Conclusion • Many of the risks were fore seen. • Lack of competence in technology created installation problem Risk Analysis 6

  7. Project Analysis - Effort Metrics Weekly effort metrics Conclusion • Equal work distribution through out the software development weeks. • Work Distribution among team members was equal except for holidays. Person effort metrics 7

  8. Financial metrics & Communication Financial metrics • The cost well within the budget. • Estimated as 25hrs/week. Actual should be 20hrs/week. Communication • Miscommunication was regarded as one of the risks. But did not prove so. • 241 messages, 65 files uploaded to btwmdh@googlegroups.com. • All barriers of cultural differences were broken to work as a team.

  9. Project Analysis – Requirement Compliance • Dropped tasks • Integration of management • Partially Implemented • Add advice types • Conflict management 9

  10. Project Testing Requirements Testing 2014-10-25 10

  11. Project Experiences Positive Experiences • Communication • Planning design • Cultural differences • Team Work • Real distributed environment • Equal workload through all weeks of development Possible improvements • Technical improvements • Documentation • Time management • Better risk analysis • Early prototype development • Time allocation for testing 2014-10-25 11

  12. Score Approach Communication with Customer • Score Supervisior recommended to find • potential user • From Common people requirement are • collected on basis of Survey and Interview by • feedback 2014-10-25 12

  13. Score Approach • Problem solving approach in Requirement Engineering • Analysis Search and Conclude (ASC) approach to • review problems • It contains simple steps that are based on reviewing problems in peers ASC (Analysis, Search and Conclude) 2014-10-25 13

  14. Score Approach Additional requirements • PATH advice management system • Adding Advice features such as Bar, Road information • according to user. • Problem faced in writing the SCORE Report • Ambigious about expectation of Steering Group about SCORE Report • No previous Experience of Writing Score Report for International • Conference • At the Beginning Lack Team work when only 2 member working on • Score report • Learning from Score Report • Able to Analyze and find ASC approach • Team work comes handy in all phase of software life cycle. 2014-10-25 14

  15. Demo

  16. Thank you& Any Questions? 16

More Related