Team YALA! Ptolemy Project Postmortem Introduction This document serves as a giant reflection over the whole project done by team YALA! Ptolemy. The postmortem notes below were collected in a meeting held with Linda Pesante who facilitated the meeting. Team Members Ashwini Bijwe (India) Lyle Holsinger (USA) Wenjiao Wang (China) Yousef Alsaeed (Saudi Arabia) Project Overview Bosch Research and Technology Center (RTC) is considering Ptolemy as a tool to be used in Bosch to model the automotive engine parts and run sophisticated analysis on those models. Ptolemy is an open source modeling tool developed by the University of California at Berkeley. It provides the ability to perform advanced analysis on models. It has the ability to transform complex models and simplify them through pattern matching. However, Ptolemy needs some enhancements to support the goals of Bosch. The fundamental problem with the existing Ptolemy tool is that Ptolemy models exist as independent XML files stored in the file system. This means that Bosch needs to manage the large number of Ptolemy models that are in the file system. This requires Ptolemy to be modified to allow the models to be stored in a persistent way that maintains hierarchical relationships between the related models. Furthermore, with the large number of models, finding a specific model can be difficult for Bosch modelers. Thus, our extension of Ptolemy must provide an efficient search mechanism so that Ptolemy users can find models in a timely manner. With these high level requirements in mind, Bosch RTC made a decision to incorporate a database into Ptolemy. Postmortem Notes 1) Why did you choose this project? a. Ashwini used the process of elimination. She did not understand what Charles said about the project, but ranked this one as second (below CASOS). b. Lyle considered the most important thing was local client. c. Yousef was interested in incorporating a database into an existing a project. He got the idea that it would be a simple effort, but large. He was particularly interested in the idea of how to map XML to a database. He liked CASOS because it was a new system that was unique. He didn’t want to work on JPL because he didn’t want a remote client. d. Alek talked to previous students and was told that it was better to get a client that is outside the university. This meant that she wanted Bosch or JPL. She got feedback that the Bosch client (Charles) was very nice. She also did not want steep learning curve. She did want to work on JPL as well because she wanted to go to California. 2) What was your original idea about what the project would be? a. Incorporation of a database into an existing open source system. 3) What did we build? a. We selected an appropriate database form Ptolemy models and built mechanisms to interface with it. It was a layered system to allow incorporation of an alternative database. 4) What was a surprise? a. Ptolemy was huge and very complex. b. Bosch did not really know what they wanted. c. The business case for the system was not clear at first. 5) How did we narrow down what we wanted? a. We talked to the client weekly. b. We created a prioritized requirements document which made expectations of the product clearer for us and for the client. c. We gained confidence that we were doing the right thing after we did the first demo. 6) To get from the initial description to the point where we were confident, what would we do? a. We collected requirements in a more structured way. Talks can be endless. b. We spent a lot of time on the prototypes and use cases, but the actual artifacts didn’t help much. Should have made it clear that they are just to gather requirements. c. We spent too much time on prototypes. Should have used a less refined method (such as a rapid paper and pencil drawing). If we had done this, we possibly could have expanded the technique to explore more features. 7) Are we happy with product? a. Yes. b. We are glad we took the time to look at other databases. c. We overcame our own perspectives on what the end product would look like. 8) What were the development challenges? a. Ptolemy has a huge code base. b. Choosing a database was difficult, as was learning how to use its APIs. 9) What decision had a really big impact? a. Using breadth-wise development was a good choice. It helped us in delivering a running system by each iteration. It also helped us in working on tasks in a parallel way. b. Using TSP as a process worked for us. It was a structured process and we, as a team, did not like chaos. It gave us a plan for the entire semester that we could track our progress against. c. Choosing the right type of database (an XML database) was a critical technical decision. d. Making Lyle the team lead in the first semester was a good move. This helped because he was more familiar with the program as he was a part-time student and only had one course besides studio. He also kept reminding the rest of the team about studio tasks because we were overwhelmed with all the assignments and work from other classes and often put studio tasks last when it came to managing our workload. 10) What decision would we change? a. At this stage, we do not think that we would change any of our decisions. The reason is that we kept an ongoing reflection and took corrective measures immediately before the issues grew bigger. 11) If something isn’t right? a. We discussed it as a team. 12) What could we do better? a. Doing things collectively did not work for us because it consumed time and got us into analysis paralysis. The good side of it is that we got to know each other. b. Having responsibilities and roles earlier would have helped. When we did adopt responsibilities and roles, it resulted in things getting done faster and better. 13) What contributed to the success of the team? a. Teamwork was a priority and everyone worked so hard to meet the deadlines for the team tasks. b. We were opened to other people’s ideas. c. We trusted each other to do the work and to have high quality. d. We understood each other. e. We understood that we were here to learn. It is OK to make mistakes. f. We set egos aside. 14) What was the nature of interaction between you and the client/mentors? a. There was a good understanding on both sides (client and team). b. One negative aspect was that the client was not demanding. This kept us wondering what exactly the client wanted out of this project. c. The client did not apply too much pressure on us. This was a good thing. We had a very cohesive team that included our mentors, the client, Berkeley, and our TSP coach. We had a very good support system from these people as well. 15) What would you bring back to industry? a. Use of a structured process. b. Collection of data to be used in reflection and improvement. c. Regular reflection on what went wrong. 16) What was the major difficulty that you faced while working on an open-source project? a. Dealing with license was difficult. Working through the process of adopting the Ptolemy license required agreement from CMU and Bosch. We were developing the code for Bosch at the same time we were contributing to the open source project. This required us to get Bosch agreement to use Ptolemy license on the code we develop and since we are CMU students we have to get CMU to agree to that as well. 17) How did you manage the open-source nature of the project? a. What made it easy for us is that we tried to minimize the dependency between what we develop and what is already there in the open-source code. This was done through careful analysis of our extension to Ptolemy during the design and architecture of our system. b. We also kept an open channel with the owners of the open-source project. We kept them in the picture of what we are doing all the time. Furthermore, they showed interest and gave valuable feedback and suggestions whenever we ask them about Ptolemy or our approach of handling certain component in the project. c. We conducted code review sessions with the owners of the open-source project to ensure that what we have done did not affect them and it met their standards. 18) What one piece of advice would you give future students? a. Put the team before yourself. b. Be smart in doing your assignments (efficient). c. Don’t be afraid to take risks. d. Don’t be afraid to commit mistakes, but be sure to learn from them. e. Treat the education as an opportunity and give it the proper priority. f. Don’t focus on the degree (e.g. don’t just “wait out the clock” until graduation – it will be a waste of money and time). g. Don’t focus only on technology, relationships matter. h. You spend a lot of time with your team, so you need to be concerned about preserving relationships.
Pages to are hidden for
"TeamYALA_Postmortem"Please download to view full document