Cell Phone Software Forum
| View previous topic :: View next topic |
| Author |
Message |
Franky
Guest
|
 Posted: Sun Apr 01, 2007 8:38 pm Post subject: Linking requirements to code for higher SPICE level |
 |
|
Hi,
the company I work for wants to introduce requirements management to
achieve a higher SPICE level. I have just been "promoted" to the team
that should make this happen. There are a lot of "know it all" QA guys
in the team. I am a software developer for small embedded systems
( 8051 ).
As I said the current focus is on requirements management. The QA guys
tell me we need to have a link from the requirements specified in the
URS into our design. They have fantasies about clicking on a link in
the URS and the exact position in our design is popping up where this
requirement is implemented. Further fantasies also link to the
location in the code.
does anyone of you has experience with linking like that?
or do you know companies that do it like this?
what kind of tools are you using to achieve it?
What do you use to describe your design ( UML? Tool? )
How does it work? good? bad?
Is this really necessary for spice level 3?
May be you know a forum or other newsgroup that can help me?
Do you have recommended reading ( books? )
Many thanks for any help!
Franky |
|
| Back to top |
|
 |
| |
Ads |
Advertising
Sponsor
|
|
H. S. Lahman
Guest
|
| Posted: Mon Apr 02, 2007 7:57 pm Post subject: Re: Linking requirements to code for higher SPICE level |
|
|
Responding to Franky...
| Quote: |
the company I work for wants to introduce requirements management to
achieve a higher SPICE level. I have just been "promoted" to the team
that should make this happen. There are a lot of "know it all" QA guys
in the team. I am a software developer for small embedded systems
( 8051 ).
As I said the current focus is on requirements management. The QA guys
tell me we need to have a link from the requirements specified in the
URS into our design. They have fantasies about clicking on a link in
the URS and the exact position in our design is popping up where this
requirement is implemented. Further fantasies also link to the
location in the code.
|
I don't know much about SPICE itself, but all of the process framework
models for software development value traceability of requirements
through the development.
However, the primary goal is to ensure that the requirements were
actually resolved in the implementation. A secondary goal is to be able
to easily check if they were actually resolved. Note that the emphasis
is on whether they were resolved, not how well they were resolved. The
process frameworks identify other infrastructures to prevent defects so
that if the requirements are resolved, they should be resolved correctly.
It is a common mistake to take process frameworks like SPICE, CMM, ISO,
et al too literally. One only needs paper trails signed in blood and
stored in a vault under the Rockies if the developers are idiots and the
shop is a zoo. If the developers are grownups and the environment is
professional, one can by with a lot less. So when trying to implement
things like traceability one should look for the minimum necessary to
fulfill the goals of the process framework. If the developers turn out
to be idiots and that doesn't work, THEN go for the bloody paper trails.
As an anecdotal data point, one approach is to employ use cases for
traceability. The customer use cases are decomposed into detailed use
cases for each subsystem. Since use cases are a form of requirements
specification, this provides direct traceability to the subsystem level.
(In UML one can use Package and Use Case Diagrams to organize the
decomposition of the use cases and associate them with subsystems.) The
finer the granularity of modularity, the fewer requirements addressed by
each subsystem use case. So the granularity of traceability is closely
tied to application partitioning.
At that point the team developing the subsystem can check off the use
case when they implement it as a simple checklist item. One can also
provide other checklists for things like whether test cases were written
for the use case, that the test cases were actually run, and that they
passed. Overall this provides pretty high visibility into whether the
requirements were implemented and all it requires is a few check marks
as the developers complete various tasks. So long as one can trust the
developers to be honest about doing the checkoffs, that traceability
infrastructure will probably be sufficient.
*************
There is nothing wrong with me that could
not be cured by a capful of Drano.
H. S. Lahman
hsl@pathfindermda.com
Pathfinder Solutions
http://www.pathfindermda.com
blog: http://pathfinderpeople.blogs.com/hslahman
"Model-Based Translation: The Next Step in Agile Development". Email
info@pathfindermda.com for your copy.
Pathfinder is hiring:
http://www.pathfindermda.com/about_us/careers_pos3.php.
(888)OOA-PATH |
|
| Back to top |
|
|
| |
Ads |
Advertising
Sponsor
|
|
Franky
Guest
|
| Posted: Mon Apr 02, 2007 11:43 pm Post subject: Re: Linking requirements to code for higher SPICE level |
|
|
Hello together,
first of all many thanks to M. Lahman for the reply.
It gave me confidence to push the pragmatic approach in the project.
I wonder why I did not get more replies. When I read about SPICE, CMMI
etc. I got the impression everybody is using it and anyone who is not
is a looser. Is this a "no" topic, here? Or is it the wrong newsgroup?
I would like to get some impressions from people who are not actually
consultants for SPICE, CMMI etc.
Many thanks,
Frank |
|
| Back to top |
|
|
| |
Ads |
Advertising
Sponsor
|
|
H. S. Lahman
Guest
|
| Posted: Tue Apr 03, 2007 8:32 pm Post subject: Re: Linking requirements to code for higher SPICE level |
|
|
Responding to Franky...
| Quote: |
It gave me confidence to push the pragmatic approach in the project.
I wonder why I did not get more replies. When I read about SPICE, CMMI
etc. I got the impression everybody is using it and anyone who is not
is a looser. Is this a "no" topic, here? Or is it the wrong newsgroup?
I would like to get some impressions from people who are not actually
consultants for SPICE, CMMI etc.
|
It's possible (albeit unlikely) that I was first to reply and others
didn't have anything to add. B-)
It's much more likely that no one on the forum knows anything specific
about SPICE. (I don't either, but there's no point in letting a detail
like that get in the way of an opinion.) Because online forums can suck
up a lot of time, people often don't respond unless they are expert in
the specific subject matter. (Since I'm retired I don't have a bandwidth
problem.)
There is an entire alphabet soup of process frameworks (SPICE, CMM, ISO,
Baldridge, 6-Sigma, et al). In total a fair number of shops have adopted
such standards. But there are relatively few adopters for any particular
process model and very few have achieved top-level accreditation in the
process framework. Also, in the context of all software shops, the total
number using process frameworks like SPICE is actually quite small.
<Hot Button>
That's sad, but things are changing. Customers are beginning to notice
that the only things that break in their lives are software and they no
long buy the argument that software is "different" and crap is justified
because of that. So providing quality software at 5-Sigma and beyond is
becoming a competitive issue. There is simply no way to do that without
having a good, self-correcting software development process.
I believe the situation for the software industry is very similar to the
situation that existed for Western manufacturing in the '70s. The PacRim
countries made quality a competitive issue and Western manufacturing had
a tough time in the '80s trying to play catch-up. I believe the software
industry is facing exactly that sort of competition-driven paradigm
shift today.
One way that is manifested is through off-shore development. In the past
decade 41% of US software development has gone off-shore. The usual
justification is cheaper labor rates. But the true cost of arm's length
management of off-shore development tend to make such differences a
wash. I think the major reason is that the off-shore shops are starting
with a clean slate. Their software industry is very new and it was
founded by listening to the software engineering academics about process
-- just like the Japanese listened to Deming after WWII. So they are
building software properly.
That translates into much less schedule variance and much better
quality. Those things are much more important to managers than labor
cost because in the long term they are manifested in time-to-market and
market share. So the Western software industry had best wake up to
process-oriented development or the entire industry is going to move
off-shore just like memory chips.
Unfortunately I am not sanguine. In the West there is huge inertia and
it is difficult for shops to change the way they do things. IMO, that is
largely due to the prevailing conventional wisdom that (A) software is
somehow different that every other engineering discipline and (B)
software development is an intensely creative activity that processes
tend to stifle. Never mind that every CE, ME, and EE has more design
standards to deal with than any SE ever dreamed of and yet they keep
churning out creative designs.
Many moons ago (early '90s) I attended an SQE conference and took an
informal poll of companies with CMM L5 shops. Two correlations stood
out. Within companies that were perceived as industry leaders in
software quality at the time (HP, IBM, Motorola, etc.) there was
actually a very wide disparity in software quality for different groups
within the company. The groups that achieved L5 were quite small and
isolated within the corporation. More interesting, the L5 groups were
invariably doing R-T/E so they were very close to the hardware
developers. Conversely the groups with the worst quality tended to be
the core IT groups that were as far from the hardware as one could get.
The moral I got out of that was that the R-T/E guys were learning from
the hardware people. By that time hardware development was very much on
the process bandwagon (e.g., testing was a process monitoring tool
rather than a reliability improvement tool). Product managers with
authority over hybrid hardware/software systems were noticing that the
hardware people had their act together while the software people didn't.
So they started mandating that the software people adopt the hardware
people's techniques. Thus the further one got from what the hardware
people had already learned, the less knowledge there was about how to do
software properly.
[In the '80s and '90s I was in an R-T/E shop. In the '80s software was
the gate on product release with 300% schedule overruns and the quality
was abysmal; the mean time to system crash was about 40 minutes. So we
got a /lot/ of pressure to clean up our act compared to the hardware
guys. So we did and adopted things like SPC from the hardware guys. When
I retired we were hitting schedules -5/+15% and our systems got an award
from the USN for 600 systems operating a decade with an average MTTF of
2.7 years, which were mostly hardware failures.
Ironically the software group had become so process-oriented that it was
out-performing the hardware group. So Management started leaning on the
hardware people to adopt our practices. When I left the Hardware Manager
was from our software team and our main attrition was providing managers
throughout the corporation.]
</Hot Button>
*************
There is nothing wrong with me that could
not be cured by a capful of Drano.
H. S. Lahman
hsl@pathfindermda.com
Pathfinder Solutions
http://www.pathfindermda.com
blog: http://pathfinderpeople.blogs.com/hslahman
"Model-Based Translation: The Next Step in Agile Development". Email
info@pathfindermda.com for your copy.
Pathfinder is hiring:
http://www.pathfindermda.com/about_us/careers_pos3.php.
(888)OOA-PATH |
|
| Back to top |
|
|
| |
Ads |
Advertising
Sponsor
|
|
Bjorn Reese
Guest
|
| Posted: Wed Apr 04, 2007 3:48 pm Post subject: Re: Linking requirements to code for higher SPICE level |
|
|
Franky wrote:
| Quote: |
As I said the current focus is on requirements management. The QA guys
tell me we need to have a link from the requirements specified in the
URS into our design. They have fantasies about clicking on a link in
the URS and the exact position in our design is popping up where this
requirement is implemented. Further fantasies also link to the
location in the code.
|
This is definitely not the first (and probably not the last) time
somebody has gotten that silly idea. They typically tend to forget that
the purpose of requirement traceability is to make sure that you do not
accidentially forget features that were promised to the customer.
There are two basic problems with their idea.
First, many requirements do not map nicely into neither design nor code.
An obvious example is, where in the design or code are you addressing
the requirement that 95% of all user requests must be handled within 1
second? I have deliberately chosen a non-functional requirement as an
example because those are easier to illustrate, but there are plenty of
functional requirements that are just as difficult to map directly into
the design or code.
Second, requirement traceability with the suggested level of detail has
a high maintenance cost, and tend make future development expensive and
inflexible. This cost may only be justified if missed requirements are
expensive (as in safety-critical software) or occurs frequently.
Given the purpose of requirement traceability, it is sufficient to trace
requirements to the test specification (which places the burden on QA :)
Disclaimer: I am not familiar with SPICE. My reply assumes that SPICE
is like CMMI in this regard.
--
mail1dotstofanetdotdk |
|
| Back to top |
|
|
| |
Ads |
Advertising
Sponsor
|
|
Andrew Gabb
Guest
|
| Posted: Sat Apr 07, 2007 9:20 pm Post subject: Re: Linking requirements to code for higher SPICE level |
|
|
Franky wrote:
| Quote: |
first of all many thanks to M. Lahman for the reply.
It gave me confidence to push the pragmatic approach in the project.
I wonder why I did not get more replies. When I read about SPICE, CMMI
etc. I got the impression everybody is using it and anyone who is not
is a looser. Is this a "no" topic, here? Or is it the wrong newsgroup?
I would like to get some impressions from people who are not actually
consultants for SPICE, CMMI etc.
|
I'm not, and it's not the wrong newsgroup.
I quickly skipped over your original post because it seemed to me
you didn't have the appropriate experience or attitude to be on the
team, and any answer which didn't reinforce your opinion wouldn't
help you. I formed this view because your questions indicated that
you thought tracing requirements to design was ridiculous.
I was also very surprised to see a reference to SPICE here. I hadn't
seen it referred to in years.
So, some opinions from me ...
I can assure you everybody's *not* using SPICE or CMMI. Far from it.
But I also suggest that any software development organisation that
sees the benefits in process and process improvement would at least
be aware of CMMI and its requirements and have compared them with
their own.
BTW, if you can't link requirements to design, how do you ensure
that you're meeting the requirements? For large and complex
projects, the test stage is a bit late. And often expensive.
Andrew
--
Andrew Gabb
email: agabb@tpgi.com.au Adelaide, South Australia
phone: +61 8 8342-1021
----- |
|
| Back to top |
|
|
| |
Ads |
Advertising
Sponsor
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
212 Attacks blocked
Powered by phpBB © 2001, 2005 phpBB Group
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
