Moderator: This room arrangement makes it possible to do panel
discussions conveniently at the round table. Everyone is encouraged to speak!
Here is a summary of what have been discussed.
* Format clue: below we denote a participant by
the first name and use a colon to lead the opinion statement. The statements
are not exact as uttered, but should be close to the meaning. Correct me
if I understood it not as intended.
* After Kevin and Elliot's invited talks about past experience, everyone
agrees, no doubt about the industrial need for a RETR solution.
* Elliot's talk brings up this question, are we reinventing the wheel?
Back in the 80's, there are quite many CASE tools in the market, but it
is extremely hard to pursuade practitioners to press the Analysze
button. What's going wrong?
Elliot: To make reverse engineering tool (or CASE tools in general) adopted, we
need to synchronize the forward engineered results with the requirements
immediately.
* What is the target of RETR?
After Hai and Ying's presentations, we are a little bit lost: Hai's talking
about abstract object states and test case generation, Ying
was talking about business data and policies. In the afternoon
we may hear more about goals and quality concerns.
George: But wait a minute, what'is the right form of requirements
since we are talking about them as the target of RETR?
Hai: Requirements in the abstract object state work are useful to
generate test cases. Test cases can be regarded as requirements.
The problem we are solving is how to reduce the number of reverse
engineered requirements so that they become understandable.
Kenny: People talking about extreme programming and test-driven
development. There is quite some agreement on test cases or
use cases being requirements...
Everyone agrees that requirements is something close to the business party,
user or other stakeholders. They are well before the design and architecture,
but to obtain them from the implementation, one has to go through some
intermediate steps, and that is what makes the problem more interesting...
* We need an industrial case study.
George: Playing with toy examples such as open-source code is not
necessarily convincing, what about the real needs in
industry? In our organization, there are quite many practical
projects to be RETR too.
Which one is easier? To revamp the requirements from source code,
or to dig them out from the metadata?
* What can be the source of RETR?
How can business policies be gathered from only the implementations
if they are lost?
Kenny: what's the difference between the if-then-else and the business
policies? How to tell a condition is relevant to business or not?
Ying: That's why we chose the 3-tier architecture to study because the business
logic may tell us what is relevant to business.
Kenny: Source code are not complete to be considered as the source of RETR,
but they are the most reliable ones
Yijun: In RE'05, we did some initial work on recovering the purposes
of programmers or the reflected purposes of other stakeholders
from the comments of the code. Matin Fowler's refactoring book
says "a comment signal a semantic gap" between the code and the
understanding. That's where we can find some of the requirements
lost from the executable code. Another possibility is to generalize
the idea of literate programming to maintain the traceability between
requirements and code from the very beginning.
Nazim: We need multiple stakeholders, not just the users,
but also programmers, maintainers, etc. Also we need to be aware
requirements are not always from the very beginning, it may arise
during the development process. Thus we should establish the
traceability among requirements and design decisions. By the end
of the day, it is possible to trace back the changes all the way
to the business partners. I will give a talk tomorrow at WICSA'05
on the subject.
* How to adapt to the changing requirements, changing people, constraints alike?
Nazim's point brings up another discussion on the changes or evolutions.
How can we identify the lost changes if we do not have the code, people
around? This come back to Elliot's earlier talk, we need to immediately
RETR after any change to the implementation.
Other topics briefly discussed, but not having time to explore much further:
* Reengineering because the technology shifts to new fashion
Kevin: We are moving into Web, C#, .NET, everytime there is a big shift
in technology, one needs to consider interoperability of existing
systems with the outside world. Sometimes you have to move
on along with the technology shift.
* Requirements from the application areas, not only the platforms
Ying: You may have the same business requirements implemented differently
in different platforms.
* New tech makes new requirements feasible
That's the topic in the afternoon, isn't it?
Every participant is free to continue submitting your opinion on the topic.
We will set up a discussion forum soon.