TeamYALA_Postmortem by huanghengdong

VIEWS: 3 PAGES: 4

									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.

								
To top