Home > Archive > Software Engineering > December 2007 > Project report requirements
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Project report requirements
|
|
| ibeleveyou@gmail.com 2007-11-23, 4:25 am |
| Hello,everyone.I need some help about project report requirements.
Do you know how many reports or documents should be made in the
process of sofeware project development .What are they? Thanks.
| |
|
| ibeleveyou wrote:
> Hello,everyone.I need some help about project report requirements.
>
> Do you know how many reports or documents should be made in the
> process of sofeware project development .What are they? Thanks.
A project should not reward its programmers for producing paperwork. That's
not always a reliable indicator of progress.
A project should release a working version once per w . Real users should
use this version, and request features for the next w. So this release
schedule is itself the progress report. Instead of documenting what features
should have been in the application, this w, the users get to actually
make use of the features.
--
Phlip
| |
| H. S. Lahman 2007-11-23, 7:07 pm |
| Responding to Ibeleveyou...
> Hello,everyone.I need some help about project report requirements.
>
> Do you know how many reports or documents should be made in the
> process of sofeware project development .What are they? Thanks.
It depends upon what process you are using to develop your software;
some have different reporting requirements than others. In the end,
though, you need the reports that enable you to do your job well.
*************
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
| |
| Alexei Polkhanov 2007-11-28, 7:10 pm |
| On Nov 23, 1:02 am, "ibeleve...@gmail.com" <ibeleve...@gmail.com>
wrote:
> Hello,everyone.I need some help about project report requirements.
>
> Do you know how many reports or documents should be made in the
> process of sofeware project development .What are they? Thanks.
List of required and optional documents generated and what they should
contain described in IEEE 12207.1 or ISO/IEC 12207 Software Life Cycle
Processes. Software Development is only a part of entire Life Cycle.
If software you are developing is not a part of bigger (not necessary
software) system then short list of documents will include at least
Software Requirements Specification (IEEE 803) Software Design
Specification (IEEE 1016), 3. Software Test Documentation, User
documentation. Among other types of documents produced I can list Code
Review reports, Maintenance plans etc.
Read the standard - it written by world's best software engineers -
collective experience of 1000s of companies and governments for more
than 30 years. As an alternative you can refer to Software Engineering
course book like Summerville's "Software Enginering". It is nice to
see that current, 8th edition, of his book is more standard compliant
than previous editions.
Alexei.
| |
| Dave Rahardja 2007-12-22, 10:09 pm |
| In article
<bd1d2899-ee9b-4737-b92f-9e99abbb96d9@d27g2000prf.googlegroups.com>,
"ibeleveyou@gmail.com" <ibeleveyou@gmail.com> wrote:
> Hello,everyone.I need some help about project report requirements.
>
> Do you know how many reports or documents should be made in the
> process of sofeware project development .What are they? Thanks.
As you have probably gathered from the other replies, the answer is: IT
DEPENDS.
It's always a good idea to ask the question, "who will read this
document?" before having your team generate it.
In some industries, there are specific government and standards bodies
that require particular documents to be submitted. In that case, those
documents become mandatory.
In other instances, documents are generated for internal maintenance. In
those cases, ask what /data/ (not documents) is needed to support your
process, and think about ways to communicate that data most effectively.
In many cases, the data you need is fleeting in nature, and does not
need to be archived. If that is true, then documents are not the best
way to communicate. Bug lists or "backlogs", feature requests, frequent
solicitation of customer feedback, etc. are often more effective.
Some cases where I think documents are appropriate include engineering
analysis of control systems (if your software is controlling some
machine), user interface guidelines (a UI design group would still be
better than a document), safety or failure analysis, and other
high-level analysis that determine the general architecture and
constraints of your product.
-dr
|
|
|
|
|