LabVIEW
project management
Hi,
At AIR we adapted GAMP3/4 (Good Automated Manufacturing Practice) to manage
projects. However, we created a Management System of our own. This new
system is more intuitive but GAMP compliant. It uses patterns to store
project management 'knowledge'.
I guess your question is more directed to the technical perspective (tools,
like VCS). *We don't use them (for now)*.
In my opinion, the usefullness of tools is only as good as the Project
Management System you use. IMHO, this is the same message you can read in
CMM (Capability Maturity Model).
Our 'trick' is to follow our Project Management System. This tells us how
(and, more important: why) we should split up a program into modules. For
each project, this is put in documents (User Requirement Specification >>
Functional Specification >> Software Design Specification), following GAMP.
Our Module Management System tells use how (and why) we should document
modules. This results in several Software Module Design Specifications. Some
needed modules may be around in our internal VI library.
All this is done *before any programming*. There is room for prototyping,
but only to make a Risk Assesment / Feasibility Study.
Because everything is modulare, we can devide responsibilities. This
decreases the need for (some aspects of) source code control. Also, a more
detailed project planning can be made. Now the programming begins.
We have detailed programming guidelines. This enables us to 'outsource' the
making of modules. The test specifications and programming guidelines are
clear, so there should be no discussion about the results. Eventually, we
could outsource the entire project!
When all the modules are completed, the only thing that remains is the
assembly. Putting it together. The software is build in standard software
architectures (documented, as any module!).
Another dimension to this all, is the testing. Each project, and each module
has test specifications. These are made upfront. During module development,
these can be used to check functionality. Afterwards, all code should comply
to these test documents (FAT/SAT/Software Module Test Specifications).
Some modeling tools/standards could be used in the documentation phase. I
haven't found a suitable one.
When everything is done this way, you'll find that the documentation is
finished before the start of the programming! Well at least about 90% of it.
Some additional information about the VI's (e.g. metrics) could be added
afterwards.
Some parts of this are still in development. A major aspect of a system like
this, is that is should always 'grow', enhance. It's a *quality enhancement
system*, not just a quality system!
I Hope it helps,
Wiebe.
Some links of interest:
CMM for software :
http://www.sei.cmu.edu/pub/documents/93.reports/pdf/tr24.93.pdf
(Search SEI for other very interresting articles.)
GAMP site : http://www.gamp.org/
About patterns : http://c2.com/cgi/wiki?PatternIndex
"Nadav Chernin" wrote in message
news:5065000000080000001C600000-1031838699000@exchange.ni.com...
> Hi all,
>
> i want know how another LabVIEWers manage big projects with number of
> developers and how they write documentation?
At AIR we adapted GAMP3/4 (Good Automated Manufacturing Practice) to manage
projects. However, we created a Management System of our own. This new
system is more intuitive but GAMP compliant. It uses patterns to store
project management 'knowledge'.
I guess your question is more directed to the technical perspective (tools,
like VCS). *We don't use them (for now)*.
In my opinion, the usefullness of tools is only as good as the Project
Management System you use. IMHO, this is the same message you can read in
CMM (Capability Maturity Model).
Our 'trick' is to follow our Project Management System. This tells us how
(and, more important: why) we should split up a program into modules. For
each project, this is put in documents (User Requirement Specification >>
Functional Specification >> Software Design Specification), following GAMP.
Our Module Management System tells use how (and why) we should document
modules. This results in several Software Module Design Specifications. Some
needed modules may be around in our internal VI library.
All this is done *before any programming*. There is room for prototyping,
but only to make a Risk Assesment / Feasibility Study.
Because everything is modulare, we can devide responsibilities. This
decreases the need for (some aspects of) source code control. Also, a more
detailed project planning can be made. Now the programming begins.
We have detailed programming guidelines. This enables us to 'outsource' the
making of modules. The test specifications and programming guidelines are
clear, so there should be no discussion about the results. Eventually, we
could outsource the entire project!
When all the modules are completed, the only thing that remains is the
assembly. Putting it together. The software is build in standard software
architectures (documented, as any module!).
Another dimension to this all, is the testing. Each project, and each module
has test specifications. These are made upfront. During module development,
these can be used to check functionality. Afterwards, all code should comply
to these test documents (FAT/SAT/Software Module Test Specifications).
Some modeling tools/standards could be used in the documentation phase. I
haven't found a suitable one.
When everything is done this way, you'll find that the documentation is
finished before the start of the programming! Well at least about 90% of it.
Some additional information about the VI's (e.g. metrics) could be added
afterwards.
Some parts of this are still in development. A major aspect of a system like
this, is that is should always 'grow', enhance. It's a *quality enhancement
system*, not just a quality system!
I Hope it helps,
Wiebe.
Some links of interest:
CMM for software :
http://www.sei.cmu.edu/pub/documents/93.reports/pdf/tr24.93.pdf
(Search SEI for other very interresting articles.)
GAMP site : http://www.gamp.org/
About patterns : http://c2.com/cgi/wiki?PatternIndex
"Nadav Chernin"
news:5065000000080000001C600000-1031838699000@exchange.ni.com...
> Hi all,
>
> i want know how another LabVIEWers manage big projects with number of
> developers and how they write documentation?
Search LabVIEW like a graph!
Some other articles about this (Rules to wire by):
http://www.ltrpub.com/insideltr/articles/article_6/article_6.htm
http://www.ltrpub.com/insideltr/articles/article_7/article_7.htm
These articles give some general tips about making 'good' software. This is
of cource a requirement for large software projects.
Regards,
Wiebe.
"Wiebe@AIR" wrote in message
news:3da5393b$0$33970$e4fe514c@dreader7.news.xs4all.nl...
> Hi,
>
> At AIR we adapted GAMP3/4 (Good Automated Manufacturing Practice) to
manage
> projects. However, we created a Management System of our own. This new
> system is more intuitive but GAMP compliant. It uses patterns to store
> project management 'knowledge'.
>
> I guess your question is more directed to the technical perspective
(tools,
> like VCS). *We don't use them (for now)*.
>
> In my opinion, the usefullness of tools is only as good as the Project
> Management System you use. IMHO, this is the same message you can read in
> CMM (Capability Maturity Model).
>
> Our 'trick' is to follow our Project Management System. This tells us how
> (and, more important: why) we should split up a program into modules. For
> each project, this is put in documents (User Requirement Specification >>
> Functional Specification >> Software Design Specification), following
GAMP.
>
> Our Module Management System tells use how (and why) we should document
> modules. This results in several Software Module Design Specifications.
Some
> needed modules may be around in our internal VI library.
>
> All this is done *before any programming*. There is room for prototyping,
> but only to make a Risk Assesment / Feasibility Study.
>
> Because everything is modulare, we can devide responsibilities. This
> decreases the need for (some aspects of) source code control. Also, a more
> detailed project planning can be made. Now the programming begins.
>
> We have detailed programming guidelines. This enables us to 'outsource'
the
> making of modules. The test specifications and programming guidelines are
> clear, so there should be no discussion about the results. Eventually, we
> could outsource the entire project!
>
> When all the modules are completed, the only thing that remains is the
> assembly. Putting it together. The software is build in standard software
> architectures (documented, as any module!).
>
> Another dimension to this all, is the testing. Each project, and each
module
> has test specifications. These are made upfront. During module
development,
> these can be used to check functionality. Afterwards, all code should
comply
> to these test documents (FAT/SAT/Software Module Test Specifications).
>
> Some modeling tools/standards could be used in the documentation phase. I
> haven't found a suitable one.
>
> When everything is done this way, you'll find that the documentation is
> finished before the start of the programming! Well at least about 90% of
it.
> Some additional information about the VI's (e.g. metrics) could be added
> afterwards.
>
> Some parts of this are still in development. A major aspect of a system
like
> this, is that is should always 'grow', enhance. It's a *quality
enhancement
> system*, not just a quality system!
>
>
> I Hope it helps,
>
> Wiebe.
>
>
> Some links of interest:
> CMM for software :
> http://www.sei.cmu.edu/pub/documents/93.reports/pdf/tr24.93.pdf
> (Search SEI for other very interresting articles.)
>
> GAMP site : http://www.gamp.org/
>
> About patterns : http://c2.com/cgi/wiki?PatternIndex
>
>
>
>
> "Nadav Chernin" wrote in message
> news:5065000000080000001C600000-1031838699000@exchange.ni.com...
> > Hi all,
> >
> > i want know how another LabVIEWers manage big projects with number of
> > developers and how they write documentation?
>
>
http://www.ltrpub.com/insideltr/articles/article_6/article_6.htm
http://www.ltrpub.com/insideltr/articles/article_7/article_7.htm
These articles give some general tips about making 'good' software. This is
of cource a requirement for large software projects.
Regards,
Wiebe.
"Wiebe@AIR"
news:3da5393b$0$33970$e4fe514c@dreader7.news.xs4all.nl...
> Hi,
>
> At AIR we adapted GAMP3/4 (Good Automated Manufacturing Practice) to
manage
> projects. However, we created a Management System of our own. This new
> system is more intuitive but GAMP compliant. It uses patterns to store
> project management 'knowledge'.
>
> I guess your question is more directed to the technical perspective
(tools,
> like VCS). *We don't use them (for now)*.
>
> In my opinion, the usefullness of tools is only as good as the Project
> Management System you use. IMHO, this is the same message you can read in
> CMM (Capability Maturity Model).
>
> Our 'trick' is to follow our Project Management System. This tells us how
> (and, more important: why) we should split up a program into modules. For
> each project, this is put in documents (User Requirement Specification >>
> Functional Specification >> Software Design Specification), following
GAMP.
>
> Our Module Management System tells use how (and why) we should document
> modules. This results in several Software Module Design Specifications.
Some
> needed modules may be around in our internal VI library.
>
> All this is done *before any programming*. There is room for prototyping,
> but only to make a Risk Assesment / Feasibility Study.
>
> Because everything is modulare, we can devide responsibilities. This
> decreases the need for (some aspects of) source code control. Also, a more
> detailed project planning can be made. Now the programming begins.
>
> We have detailed programming guidelines. This enables us to 'outsource'
the
> making of modules. The test specifications and programming guidelines are
> clear, so there should be no discussion about the results. Eventually, we
> could outsource the entire project!
>
> When all the modules are completed, the only thing that remains is the
> assembly. Putting it together. The software is build in standard software
> architectures (documented, as any module!).
>
> Another dimension to this all, is the testing. Each project, and each
module
> has test specifications. These are made upfront. During module
development,
> these can be used to check functionality. Afterwards, all code should
comply
> to these test documents (FAT/SAT/Software Module Test Specifications).
>
> Some modeling tools/standards could be used in the documentation phase. I
> haven't found a suitable one.
>
> When everything is done this way, you'll find that the documentation is
> finished before the start of the programming! Well at least about 90% of
it.
> Some additional information about the VI's (e.g. metrics) could be added
> afterwards.
>
> Some parts of this are still in development. A major aspect of a system
like
> this, is that is should always 'grow', enhance. It's a *quality
enhancement
> system*, not just a quality system!
>
>
> I Hope it helps,
>
> Wiebe.
>
>
> Some links of interest:
> CMM for software :
> http://www.sei.cmu.edu/pub/documents/93.reports/pdf/tr24.93.pdf
> (Search SEI for other very interresting articles.)
>
> GAMP site : http://www.gamp.org/
>
> About patterns : http://c2.com/cgi/wiki?PatternIndex
>
>
>
>
> "Nadav Chernin"
> news:5065000000080000001C600000-1031838699000@exchange.ni.com...
> > Hi all,
> >
> > i want know how another LabVIEWers manage big projects with number of
> > developers and how they write documentation?
>
>
