FACEO5 is an MSE 2009-2010 team that consists of five full-time members. Our team is very diverse. We
have a team representing 5 nation’s cultures (Netherlands, Mexican, Indian, Japanese, and American),
and talking different languages (Spanish, Japanese, English, Hindi). Our mentors are Matt Bass and Scott
Hissam and our clients are David Garlan and Bradley Schmerl, from the Institute of Software
Research. Our project consists of building a workflow tool with web-based GUI front-end for a service-
oriented architecture system called SORASCS. The hosted services are tools built by the Center for
Computational Analysis of Social and Organizational Systems (CASOS) lab at CMU that are used to
perform dynamic network analysis. Our tool allows non-technical analysts to graphically compose,
execute, and analyze a workflow of these services.
1. Project description vs. real product
Some team members very initially had thought that the project might be something on Eclipse with
graphical modeling tools. Initially, we thought it would be much more grounded in the domain of
dynamic network analysis. Some team members thought it would be a web interface, similar to
Yahoo Pipes. Some team members thought we would be getting into the social analysis algorithms
themselves. Real product we built is a web-based workflow construction, execution and analyses
2. How would we describe the product that we built, right now?
A web front-end to integrate CMU’s CASOS lab’s stove-piped tools capabilities via the SORASCS
interface. Team thinks they achieved the primary purpose of tying the Dynamic Network Analysis
(DNA) tools and provide the front-end interface to the users. Whether those web-service or thick
components work or not is not our responsibility. We achieved composition, execution and analyses
of the workflows on the web. We feel that we achieved the “simplicity” usability aspect for non-
novice users, like Yahoo Pipes. We feel that we built more than what was expected -- infrastructure
could be reused.
3. At what point did you realize that this was going to be the product, from your original assumptions
when did it “gel”?
When we picked WireIt open-source graphical framework! It was a key turning point in our project
in the spring. Maybe a month into the spring -- we did a demonstration of the graphical interface to
Dr. Garlan and Dr. Schmerl and things started to move on from there.
We got a simple workflow use-case from our clients and we experimented with it using the WireIt
framework to test out its capabilities as well as understand some details on our interface with our
external dependency of SORASCS. This gave us some more confidence in realizing some of our
assumptions or unknowns that we were dealing with in the project and realization of what our
product would be.
4. How painful/painless were the workflow tool’s evaluations?
The workflow tool evaluations were not that painful within the team because it helped us to
learn about the domain of workflow tools. It was a learning experience and was not a rigid
However, demoing the tools to Dr. Garlan was "interesting" because he gets into details during
the demo that we weren't prepared for and we lost the "big picture."
5. How did you feel about using open source software?
It went pretty smoothly -- we picked a stable release so it wasn't changing out from under us. We
were able to implement features using WireIt as a base. The documentation wasn't that great but
the code was solid. They had a well written wiki. Also it is built on top of YUI(Yahoo User Interface)
which is well documented and well supported.
6. What other decisions had a positive impact?
Re-shuffling and re-planning our architecture in the spring.
In Spring, taking a deeper look at what OUP suggests to do for each discipline roles and trying to
use them based on what we knew of our team and project.
Introduction of scoreboard after MOSP in the spring.
Letting go of “earned-value” for project tracking and introducing “daily burndown” charts in the
Planning poker estimation to do release planning was a good decision.
Using “proposal” driven studio to our own advantage. Propose the activities we will do in our
own “roles” or “disciplines”, jot them down on a wiki page saying “let me try this” and if it’s not
working have team member reflect on it right away and modify or change it. It also helped our
EOSP because all the activities and reflections were in there.
Having initial WBS. First Eduardo meeting was good -- we still do what he told us to do. He
basically made us realize that all we have is a set budget to work with. He's very good at
estimation and planning and broke things down for us in very simple terms. It was our first basis
of planning and then we tailored it over time.
7. Why was OUP such a good choice?
We are using Open-UP process which is an agile version of RUP. We discovered that Open-UP
process fits very well with the size of our team and our project characteristics. Our project
characteristics are that our team size was small and co-located, domain knowledge was minimal
from both team and client side, requirements are volatile throughout the project, not enough end-
user representation, and project is taking place in a research environment still adhering the team to
follow best software engineering practices with constant reflections on our learning which is a
purpose of being an MSE Studio team. Open-UP has very good role definitions. It gave us guidance
that we could follow when needed as a complete process that gave us everything we needed, unlike
Because Open-UP is agile there are some areas where team had to make decisions to use certain
techniques that are not prescribed by Open-UP in various disciplines to keep the project on track
and use process to help “routine-ize” our daily work. The agile nature of the process helped the
team to refine the process further to their own needs, where Open-UP provided the structured
process framework under which you could plan all the discipline activities according to your project
characteristics. For example, in requirements elicitation we used various elicitation techniques
besides Use-Cases to gather requirements. It is very customizable, helps you get started which is the
hard part. Gives you enough info to get started but it's agile enough to be tailored. We were able to
augment OUP with ACDM, which was another good decision. For architecture and low-level design,
we adopted the ACDM process and design cycles within the Open-UP iterations during the
elaboration phase of the project. ACDM is more prescriptive than Open-UP on how to start the
design from scratch when there are still many knowns in the project and requirements are volatile.
ACDM has an experiment-based structure that worked out well for us, and helped us to focus and
narrow down our scope on what is important in the things that we don't know. Instead of learning
everything about the technology -- control our technical inclinations to learn everything and go in all
directions. From planning point of view, it provided us a framework of iterative development from
requirement elicitation to design development to software development.
8. We liked OUP and augmented with ACDM. How much did your process change from when we
picked OUP to when we were done changing it?
We made the roles stronger. We reduced meeting time and did more individual work. We
augmented the processes to “increase the transparency in tracking and communication.” OUP is
very use-case-driven, and we didn't use it that much in the fall/spring.
9. Are there any decisions that we regret? If we had to do it again, that we would never have made.
Z model in the fall. It was a good learning experience but we couldn't use it.
In the fall everyone tried to do everything all together, we tried to get everything right and all
agreed on everything all as a team, but that's not just possible. It created a lot of stress and
took a lot of time, and the spring it was better because we focused more on the roles.
Using earned value in fall for project tracking. :( :( :( It might be good in some cases where more
is known about your project, team productivity and you can estimate the whole project but it
wasn't good for us, at least to begin the project tracking with this technique when things are not
We tried to follow other teams in the past -- we saw them doing earned value and so we
decided to do it. We also started out with templates from past teams for MOSP/EOSP but they
it didn’t show or reflect “us” as a team. We realized this after first EOSP and drastically changed
our style of reflecting for EOSP which was a good team decision.
A lot of things we had to do wrong in order to learn how to do it right.
10. Tell me more about the strengths of use cases.
In implementation it helped to list the possible scenarios for a particular requirement which was
good. Did it work with the clients? The glossary of terms was always an issue, and there were some
key use cases that they never brought up. A lot of new features were brought up randomly, like
binding/packaging. The usefulness of high-level use cases in the architecture that it might've been
more useful to have in the fall rather than the ones we had defined earlier with the client. It's useful
to decompose the requirements into a single string. It also helps for the definition of test cases. It's
also useful for making the sequence diagram to see what's involved.
11. Did we “reinvent the wheel” anywhere?
From product point of view, nothing we can really think of.
12. Tell me about other aspects of the process that really helped during development.
Having a “good enough” SRS because it was the driver for architecture, release plan, etc. For
our project having a perfect SRS is impossible.
Design collaboration -- assigning time for other people to discuss how to implement
requirements. It helped to think about many options as a low level design and many
alternative/edge cases that were easier to find when discussing it with other people. It was a bit
of an overhead but it was effective.
UI specifications came in very handy. It was good for testing, design contract, etc.
Setting deadlines for the clients who were out of town most of the summer.
Planning poker was helpful. We did long-term-ish planning for the first time and helped us to do
scoping at the right time. Helped with re-planning -- it was good enough to move on. It was
lightweight and more enjoyable. It prompted discussion when the estimated numbers were
different between team-members.
13. Is there anything about our processes that got in the way?
Earned value... our team just couldn’t make it work and it caused frustration.
Late jar! The line between "paying" and “not paying” wasn't always clear. We got both these
ideas from other teams, neither of them were in OUP.
14. Tell me about handling scope. What prompted the re-scoping?
We re-scoped once during implementation phase. Our planning and estimation and replanning
based on what we knew then allowed us to see “ahead” of time that we may not be able to meet
the project schedule. Also, SORASCS didn't make as much progress as we hoped and we had direct
dependencies with their schedule.
15. How were your overall planning processes?
We evolved a lot in planning and eventually reached a good stage. Trying to achieve perfection
would've been difficult. We were never really able to please the mentor and answer the “how do
you know” questions -- but for now we've gotten processes that work for us.
It's important to be able to look ahead, and we're able to do that. We were able to re-scope
partially because our planning was sufficiently sophisticated.
We pretty much always underestimated -- we must just be a team of optimists. There are
complicated dependencies, and also estimations are not always one-size-fits-all when we made
estimation as a team.
16. Did we start using a tool that we dropped later?
We looked into Microsoft Project but didn't really use it because it would've been an overhead. We
used to have a lot more things in Word and Google docs but we shifted more to having things in lists
on SharePoint and on the wiki. Our SRS is now in the VP UML tool that exports an excel.
17. Were there other people whose expertise we used?
Dr. Eduardo Miranda for planning and estimation.
Professor Tony Lattanze for architecture expertise.
Our mentor Scott to be concrete and prescriptive.
Jenna Date for Usability know-how.
Vikram Subramaniam our senior MSIT student for Software Risk Evaluation.
Raúl Alejandro Véjar Llugany for SharePoint. We spent a lot of time setting up the tools
18. How do you feel about what you built?
We as a team feel proud of each other to build this product together. We do think that we have a lot
of bugs compared to our industry experience. Maybe we could have improved but we didn't have
time. We feel we did a good job given our project characteristics and built something novel and it
met their basic requirements. Considering how many features we implemented we're in good
shape. We could've had fewer features and fewer bugs but for what the clients wanted we did well.
19. How did our proposals help in EOSP?
Having a list of things that we did and why we did them and having reflections in one place. Having
one person/role in charge of the proposal to keep it up-to-date, and everyone was responsible for
reflecting. We did our reflections as a 5-step process. Reflect at end of every iteration; write
reflections of our activities or technique in proposal, gather as a team before EOSP to derive high
level lessons to tell the EOSP story from things we learnt and reflected throughout the semester, use
our proposal reflections to fit in this story and lessons as data points, do the EOSP draft and
1. Let's talk about the team. What's strength of the team?
Having three girls. :D Bakery and nagging. Work gets done on time.
Everyone on the team is a well-wisher, everyone has strengths and they're willing to help each
other. We're very technically proficient. Also, good industry experience from various
disciplines. There was a “soothing force” of experience to help us out of hard times.
We were very collaborative -- even if something was assigned to one person everyone on the
team was interested and willing to help. People show interest in working with you. We would
share our notes with each other, and a sense of cooperation.
We had dedicated and hard-working team-members. We worked hard and got things done even
when we were burned out. Even when people were tired or had low morale we still worked
hard and got things done.
We have different areas of strength, not only technical expertise. Like presentations or
documentation or preciseness. Our strengths complement each other.
Everyone experienced all the roles to shift responsibilities and its pain-points. Each role built
upon the previous person in that role. We progressed very well from the beginning to the end
and built upon each other's work.
We learned as a team-member to “listen” and “co-operate” keeping learning perspective.
2. It sounds like we got better at “letting go” -- we started out being a group of perfectionists but it
sounds like we loosened up later. Did it evolve or did it happen all at once? Was there angst?
In the fall we were sticking to our ideas and had a lot of discussion, but we were stubborn. At some
point in the spring we started being more like “let's try it” -- we were more open to other people's
ideas and taking disagreements as “learning opportunities.” We evolved from being stubborn
individualists to a team of 5. The EOSPs/MOSPs were a lot less painful after the fall, which is an
indication of how we were more on the same page with each other.
3. Tell me about the scoreboard. Why was it effective?
The comments were good and we actually used it. If something is “turning red” we knew that we
would have to change something right away. We used it actively as a tool: we checked the
score/comments in team meetings and made certain actions when we found something we needed
to improve. It also helped because team members communicate differently. It let the team
accumulate all their thoughts for the week in one place to make sure that things got read.
We tried to accommodate people's different communication styles. For example, some team
members hated doing slides, so we won’t give them slide work and more development work. We
started learning who was good at what and who enjoyed what and tried to accommodate what
people felt more comfortable with keeping learning perspective in mind.
In the beginning it was hard for the team to say “no,” but we're better at it now. :D. The design
collaboration process started largely because of scoreboard comments. Planning was always low so
it was encouraging to always try to improve our processes via scoreboard comments.
4. What aspect of your team, knowing what you know now and knowing the people, would you have
done sooner to overcome sooner or differently to overcome a weakness? What were the hard
parts? What aspects of working together either still need improvements or got improved along the
Different people having different expectations. It takes time to understand different people's
strengths in different areas, and we're always switching roles.
Everyone has different viewpoints, and it’s hard to know what's out of the standards for other team-
member and what's good enough for me. This could delay in building trust.
Being democratic initially may have hurt us. The learning curve was a bit steep with the diversity on
5. What do you consider a turning point and how did team evolve?
Some key useful milestones and decisions
Using different requirements elicitation techniques and figuring out what worked and what
didn't. Methods class was a forcing function here. We also had basic high-level use cases in the
fall to understand the project. Evaluation of some existing workflow tools to understand the
domain better. First SRS draft in the fall after collecting set of requirements using various
Notional architecture that we put on paper showing how our tool might be broken down with
external dependency of SORASCS.
Having the initial set of project management tools infrastructure set up in fall (SharePoint and
then wiki) to help our planning and tracking process evolve over time.
Picking OpenUP as our process framework.
Planning in the spring, when we started utilizing the process better.
Technology evaluation of the open-source graphical frameworks in Fall and Wire-It demo to our
clients in the spring.
Architecture helped the team bond because we were technical.
Prototype helped morale and the team missed programming.
Stopping the workflow workshop -- realizing it wasn't helping us and refocusing.
Our team is very diverse. We have a team representing 5 nation’s cultures (Netherlands, Mexican,
Indian, Japanese, and American), and talking different languages (Spanish, Japanese, English, Hindi)
During Inception phase (Fall semester) team struggled with overall project including planning as well as
getting things done in all the disciplines due to the fact that we were all new to the MSE program, new
to each other in terms of knowing each one’s kinks, stress-points and personalities, and new to
understanding how to deal with our clients to gather requirements. During first month of elaboration
phase (Spring semester), we still struggled with planning and getting the design work started while the
requirements were still volatile. However, it was the second month of Inception phase when team
started to really come together, where we saw each of the discipline roles taking initiatives in changing
things around based on the downfalls we were constantly facing. Team members were more openly
communicating with respect to issues we were having with each other or as a team as a result providing
a helping hand in the area that needed most attention. Team dynamics started improving because of
lines of communication opening as well as roles becoming more real and defined. The project
management in our team was real at this point where we were asked to reflect and change as things
didn’t work every iteration to improve and put the agreed upon milestones and quality deliverable out .
After getting hit hard in Inception and beginning of Elaboration, small wins of getting things done were
big wins in terms of overall team dynamics. We found that human side of software engineering are the
toughest part to deal with even when you have brightest of the minds within your team as well as
technical clients and mentors.
6. What has been your favorite part of the studio project?
Favorite part of studio project has been really *all* of it. Whole project has been an experience so far
where you get to treat 16 months software project as your own *software engineering sand-box* where
you can try out your ideas on following best practices while putting a real product out, working with
bright minds and different cultures and personalities that challenge you throughout to make things work
in midst of uncertainty. We feel that our team is real, our project is real, our clients are real and
program demands are real outputs from studio point of view.
One of the things that we really like in our project is there is *constant* learning opportunity that the
team recognizes and embraces from technical to non-technical point of view. The area of dynamic
network analysis, workflow technologies, service oriented architecture, and all of this on the web
platform is the challenge for the team and project. Taking upon a different role each phase (requirement
analyst, to architect to project manager to tester to developer etc) allows you to feel both the joys and
pains of each area.
Client and Mentors
1. Let's talk about your client. What was most challenging and what went best?
They tried to present a unified front but they did not seem to be on the same page. Dr. Schmerl had
three roles (client, SORASCS developer and technical lead) and they weren't really compatible and
Dr. Garlan being so busy at times was out of loop and we had to “re-define” the context to always
bring him up to speed with current happenings and decisions.
We learned better ways of working with Dr. Schmerl in a more informal setting to get things done.
Dr. Garlan has “abstract” ideas but is usually very consistent. His end goal seemed to be to always
help us out. He sometimes came up with ideas that were trying to help us.
2. When did we figure out that we needed to manage our clients instead of following exactly when we
were learning? When did we get frustrated enough?
We didn't initially realize the consequences of leaving everything up to them until it hit us hard with
our schedule and team interactions. Spring's planning was a big wake-up call for client interaction,
because we started realizing how much we needed to get done and they weren't.
We gained confidence by making small decisions like WireIt and stopping the workflow workshops
to take matters into our own hands. Initially we were waiting for them to give us what we need, but
eventually learned to make decisions on our own.
Workflow workshops -- giving options is good sometimes but not always. We need to come up with
the options, and the clients sometimes wanted everything we talked about. We often had to cut off
Dr. Garlan in the meetings before he digressed too far.
3. Do you think that we met our clients' expectations? What do you think they think right now? Are
It's very hard to satisfy Dr. Garlan. We don’t think that he is dis-satisfied but we don’t feel that we
have met his standard.
4. Knowing what you know now, how would you have approached your clients? You had to find things
Now we know what we should discuss vs. what we should avoid in front of Dr. Garlan. We've
learned where he'll digress and what would capture his imagination. He provided a lot of guidance
that ended up being helpful -- for example, from the beginning he emphasized the importance of
choosing the graphical framework.
5. How did we manage when they would get into details?
Cutting them short, saying “we'll consider it”, learning what not to discuss. Realizing what the two
clients are not on the same page about, and then discuss it when the two of them are together. Our
clients liked demos, technical details and not documents.
6. What were the most effective ways to communicate with the clients?
Specific agenda and sticking to them.
When they pushed things such as saying – “we'll revisit”.....we would say “but when??” and try
to set deadline or its priority and importance.
We always sent the agenda ahead of time.
We were never really able to gauge if they were satisfied or not.
They liked UI specifications and would actually respond to those. They liked concrete things like
demos and technical discussions. What Dr. Schmerl really needs to do to get this requirement
to work. When we were just discussing the SRS he wasn't very pro-active, but when we started
doing architecture he started paying attention.
QAW didn't work well. It was a very abstract discussion, and they weren't even sure of the
inputs they were providing to us with respect to some scenarios. Dr. Garlan didn't really want to
do it, and Matt started mentoring us, and Mike Bigrigg started putting in random ideas...
7. Did we experience problems with Dr. Garlan's multiple roles?
No, he was fairly consistent, but not always predictable. Dealing with Dr. Garlan was sometimes
stressful because we weren't always sure where the conversation would go and where it would take
8. What about our mentors?
Our first mentor meeting was very stressful. According to our mentors it was the “most dissatisfying
meeting” they had ever had. We had to learn how much to take from them and what to ignore
because they don't always know the whole situation in the team. Scott is very technical and
comparatively easy to satisfy. Scott you have to go with a question to ask. Without a question you
couldn't start a meeting. He takes meticulous notes and follows up in future meetings.
Matt encouraged us to be less ad hoc by and helped thinking of architecture from process point of
view. He would give us direction. Matt would start with “how's it going?” and Scott would start with
“what do we have today?” The two mentors helped us with EOSP. In the dry runs they would give
many comments and feedback and helped us to improve the presentation a lot. They helped us to
be unique and gave us structure to our reflections.
9. If future students had our mentors, what would we recommend to get the most out of them?
Learn what feedback is most appropriate and what you can ignore. Don't look at the mentors like
they'll help you in the project -- they're not your guiding direction. Don't be dependent on them. Be
aware that Scott is very busy. Don't expect to hear about things that you're doing right -- that's not
their job. Don't expect to be praised, you'll be told what you're doing wrong. Do EOSP dry-runs with
them and doing them twice really helps.
Advise to future MSE students
1. Look forward now. You've had a lot of experience and classes. When you're on a job, what might
you take with you?
Proposals. Think ahead of what I really want to achieve and what's the approach to get there,
and how can we analyze if we are achieving the goal. It's really important for everything.
Project management was a skill that we didn't have before coming here and learned a lot about.
Being in a diverse environment helped us pick up some people management skills that we'll be
able to take back.
Where use-cases could come really handy. Estimation from Prof. Eduardo and use of the WBS,
Say “it depends” to everything!
When to stop? What is “good enough” -- it's hard to make those decisions when you have so
many opinions and external factors. In the project we had many cases where we just had to say
“good enough” in order to keep moving. It was good to experience here in a smaller project.
When to feel that confidence of “good enough” is an important skill.
Our project was also technically challenging, so we all learned some new technical skills.
Certain process framework matches with certain project characteristics, so we really need to
pick up a suitable process. For example our project would not go well with Waterfall-ish process.
2. Is there any topic that is important to discuss that hasn’t come up just by my prompting?
We haven't talked about having a personal life, which is telling in itself how hard it was.
3. How was the adjustment coming from a job into the program?
The classes were the easy adjustment. The studio project was a hard adjustment because you
have to be self-disciplined to get things done in a strange environment with strange people.
In industry you often start with just coding, so it was a big change in the studio project. So much
thought process to go through in advance before any coding.
Taking charge of a role -- authority and respecting each other's authority. In real industry
there's a hierarchy so you don't have to worry about certain things. Here everything is on your
shoulders, you have to worry about everything. You're not just doing a piece of the project, and
depending on other people/teams for integration etc., you're responsible for the whole thing.
4. If you could give one piece of advice to future students, one sentence, what would you tell those
students? What do you wish somebody would've said to you a year ago “MSE Students pearls of
Be prepared to do things wrong, but have an idea of how to know you're doing it wrong.
Remember it's a school project, so don't take it too seriously and focus on the learning
Decide what is good enough -- it's a learning experience. It’s okay to take “wrong” steps as you
will quickly discover its wrong and change it.
Take the time to take classes and explore outside things that interest you or you'll go crazy.
Take on things you're not entirely comfortable with, because studio is a perfect software
sandbox to try out pain-points.
Encourage others to take on things they're not comfortable with in your team providing help
along the way.
Recognize that there are going to be differences, but everyone is on the same boat and trying to
achieve the same objective.
You're a team over here, you're not just an individual -- keep this perspective in mind and things
will be easier.
Use your architecture class to help the project, and go to Tony for architecture reviews, he is
Having defined roles is a must to be able to work individually, with least overhead but having a
team attitude is important to deliver a quality product with good team dynamics.
Constant reflections and making changes based on those reflections are must for constant team,
process, and product improvement.
You will not be able to please everybody (team-members, clients, mentors, SEI EOSP board of
panels and other stakeholders).