August 7, 2003
Date Revision Description Author
08/07/03 1.0 Initial creation Nataliya Shevchenko
Context and Team
The goal of this project is to develop a model compiler tool for the field of model-based
embedded software development (MoBIES). A model compiler is a tool that
automatically composes a larger assembly from a set of sub-models and an architectural
description of the arrangement of the sub-models. It ensures full connectivity of all
control flow and data flow signals between sub-models in the assembly, proper
sequencing of sub-models, and compatibility of sub-models. The product is being
developed for Ford Motor Company by Team Synergy of School of Computer Science,
Carnegie Mellon University.
Ken Butts, Ford Motor Company: Ken Butts is the primary sponsor at Ford. He is an
advocate of model-based development techniques within Ford. Ken does not push back
on suggestions which makes it difficult to determine which items are most important. He
also has a large number of needed features making it difficult to determine is priorities.
However, Ken is very willing to set a list of priorities and minimum requirements when
Bill Milam, Ford Motor Company: Bill has lots of ideas and is outspoken about them. Bill
is a great source for future enhancements. He will continue to make more requests until
the schedule is clear to him. Once he is aware of the time constraints he will readily
indicate the highest priority items.
Kanat Abirov – full-time MSIT/MSE program international (Kazakhstan) student, who
joined the team as part-time sub-contractor during spring semester, and became full-
time team member for a summer semester.
Manny Bhojwani – part-time MSE program student, who left the team after fall semester.
Greg Bylenok – full-time MSE program student.
Goran Momiroski – part-time MSE program international (Macedonia) student.
Nataliya Shevchenko - part-time MSE program international (Ukraine) student.
Kevin Steppe – full-time MSE program student.
After 5 months of work on the project, team Synergy had a clear definition of product
requirements, had UI prototype and a draft of architetcture. On February 28, the team
had a series of meetings with the client.
At the first meeting the team and client narrowed down the scope of the project and
agreed upon a minimal set of project deliverables. The team found that UI prototype of
the system was more useful then the system architecture to discuss team’s decisions
and product issues with the client.
The second meeting was a Software Risks Evaluation session led by a SEI risk expert
Ray Williams. The team identified uncertain scope as a major risk for success of the
project. After that meeting the client and team agreed on the minimum acceptable
scope for the project.
However, the team believes it spent a lot of time and effort on requirements elicitation
during the fall semester. Especially, the team spent a lot of time prioritizing the
requirements. Based upon these insights the team believes that scope issues or
requirements elicitation problems could have been solved in the following ways:
Have client meetings early in the project. In our case, have the meetings at
beginning of the fall semester.
Get requirements early in the project (the fall semester)
Make UI prototypes early in the project (the fall semester)
Get the client to prioritize requirements that the team and the client have
identified – this is the client’s job, not the team’s.
Use software methodologies such as problem frames and task analysis early in
the project to get a solid understanding and definition of the client’s needs.
At the beginning of the project, our client told us about Vanderbilt’s tool – GME – which
he had evaluated before. As it provided him with some of the desired features, we
considered it to be a competing product. Exploring Vanderbilt’s tool we learned some of
the client preferences and got a better understanding of the problem.
Our client wanted us to evaluate both GME and AcmeStudio (developed by Garlan’s
group) and pick one as a basis for our product. We considered a number of factors in
making a choice. A full analysis can be found in our spring design document. We did
not make a decision until early in the spring. This delay caused other delays in our
development process as a result.
There are several lessons learned from this experience:
Pick tool early.
Pick one and commit to it.
If the difference is big enough to matter, it should be obvious, otherwise just pick.
As an architecture analysis our team used an ATAM conducted by Rick Kazman. For us
it was a beneficial, but discrepant experience. We felt that did not understand the
method well enough to perform it, and thus were poorly prepared. We decided that a
series of mini-ATAMs would have been more helpful – the first would identify the utility
tree and introduce us to the method while the second and later sessions would flesh out
Thus, resume of our experience with ATAM is:
It’s very important to have intro session before preparation for ATAM.
The utility tree is valuable even without the rest of the ATAM.
Mini-ATAMs will be more useful for studio if they are performed incrementally
rather than as a one-time event.
It’s good to work with an SEI expert. Try to work with people from SEI even
outside of ATAM or other SEI methods.
Software Requirements Engineering was useful in general to understand and structure a
process of requirement elicitation and analysis. We used formal and informal interviews,
brainstorms, built use cases and collaboration diagrams, created vision document and
SRS. But not everything was as useful for us.
For example, the vision document was not useful. Our client has developed the product
idea for three years, and has already documented the vision. The use-cases were not
very useful for us either. Our product has only one user at a time. During the time of the
class the requirements were not nailed down. In this case, we developed about 20 high
level use cases, which we never used. We decided that a UI prototype would have been
much more useful for us.
Methods of Software Development had a couple of useful and interesting techniques.
The usability section required a paper prototype. That prototype helped the team
understand what the product would look like, how it would work, and built a consensus
for functionality. The functional decompositions diagrams helped us communicate how
the system would be structured. Finally the design patterns were useful in a few areas
of the system such as the bridge, and the model reader/writer.
Our team had diverse knowledge, experience and work patterns. Also, this was a very
multi-cultural team. These factors as well as fact that most of us have strong personalities
shaped evolution of our team and processes in our team.
The beginning was chaotic with poor communication and difficulty making decisions.
We tried to hide behind TSP roles. We faced these issues at the end of the fall semester
during first post-mortem session.
At the beginning of the spring semester when of our more forceful personalities left the
team. We also radically changed our process, removing half the TSP roles, and
concentrating on a team view of the tasks.
Below are some thoughts and decisions which helped our team succeed in our studio
Studio is not the place for competition. Be aware if you come from a competitive
Mentors like to know what is happening, so spam the with all of your
communication in the beginning, and reduce according to their requests.
Communicate as much as possible within the team early.
Mentor’s expectations are very important, ask for them early.
The mentors can be a risk.
A technical writer is very helpful for the team, so try to include him/her in the
Email may be not enough for good communication in the team, so use telephone.
You will be very busy, so set family expectations from the very beginning.
For part-timers it’s critical to set boss’s expectations early.
Other teams are a good resource of ideas, make time to meet with them.
Faculty and other CMU and SEI resources are available, so use them as much as
A formal process for review is helpful, especially when deadlines are slipping.
2 week cycles are best for the fall and spring.
Process need to be adjusted in general every semester, and in details every 2
Other teams’ processes are the source for ideas.
Mistakes are ok, if you learn from them.
Minimal role set – team lead and planning manager, others are optional.
Documentation needs to be created only if it is required, do not spend too much
time on it.
Presentations are important, but do not spend too much time on it.
Pay attention to both the high level plan and the detailed plan.
Things have to be chosen by individual – volunteering with respect of interest,
skill and time.
Planning manager makes tasks set and first estimation.
Re-estimate tasks after the task has been started.
Team Synergy had two SRE session meetings led by SEI expert Ray Williams. At the
first meeting the team and the client defined the success and failure terms of the project.
The team came up with a list of risks that could have negative effects on the project (the
format of risk list was condition-consequence). The risk meeting was very successful
according to the client’s and the team’s feedback. The SRE meeting was successful for
the following reasons:
The team had chosen the underlying technology for the project, so it was easier to
concentrate on the goals and the problems basing upon that technology.
The team already created UI prototypes based on the chosen technology.
The client was already familiarized with the team’s decisions concerning
technology through the UI prototypes.
The second meeting was held without the client. The main goal of the meeting was to
group related risk items into risk sections and define their common risk mitigation
strategies. After this meeting the team had a solid definition of risks and their mitigation
strategies. The team used the risk plan throughout the two last semesters. But the risk
plan was more intensively used and updated in the summer semester. We say the
following benefits from performing the risk planning process:
The team is aware of critical problems and stays focused on them.
Project planning process is more efficient and adequate reflecting critical
Team resources are allocated more adequately and efficiently.
Our customer was not local, which made interactions with the client a more prevalent
issue in the studio. We found that there is no substitute for face-to-face communication.
In our case, Ken was willing to visit, but we did not take as much advantage as we could
have. We suggestd that future studios with remote customers arrange a visit at least
once a semester. We also found informing the client that a lack of clear priorities is a
serious risk to our success to be very effective in getting those priorities.
We were the first studio team to ever use subcontractors. Overall, the experience was
positive. We got more work out than we could have by ourselves for the same time
expenditure. We also got the work done earlier. A number of things helped make it a
The work was done in the spring giving us time to rework or recover if they didn’t
The piece we gave them was scheduled for later, so our spring work wasn’t
dependent on them. However, it turned out that their work had some
dependencies on us.
The team chose our project, which helped in their motivation and interest.
Kevin attended all of their team meetings to answer questions.
The work was self-contained in the sense that it could be tested independently.
Future teams considering subcontracting should keep the following in mind:
Keep in close contact with the professor, Eric Nyberg. The SEIT projects are
handled by him personally.
Be available to the SEIT team for questions, and stay visible to them.
Be very specific about code expectations such as:
o Package structure for java classes
o Logging frameworks
o Code style
Expect to spend time reworking some things. It is very difficult to express
requirements for code explicitly enough to get exactly what is needed in a short
period of time. Additionally, later discoveries can lead to rework, especially
externally developed code.
At the beginning of the summer we took on one of the MSIT students (Kanat Abirov) as
a team member. The defining moment for inclusion was when the team could assign
takes to him. The addition was a success and the following all helped:
Prior knowledge – Kanat worked with the team in the fall and spring.
Making the relationship, expectations, and priorities clear
Building the MSIT student’s practicum into the schedule
Finding overlap between team tasks and practicum tasks
Involving him in team wide activities such as architecture or risk tracking
Good time management from the student
Some final words of wisdom for future studio’s:
Remember that studio is not an industry project, with different objectives –
identify them early and stick to them
Studio is not just about the product; it is also about the people and process. Pay
attention to the process and people as well as the product. Start the process at
For part-timers it’s particularly important to spend as much time as you can with
the team members.
Concentrate on taking advantage of the resources at CMU; you’ll need to put
forth the effort to make that happen. If that requires cutting scope then do so.
And lastly, start on the right foot in the fall, it will make the summer a lot easier.