Hi wise_princess!
As a computer software analyst/designer/developer (in both organized
and disorganized shops) for more than 15 years, I had no problem
coming up with what I believe to be 4 extremely important
methodologies for Software Development (I will use COBOL pseudo-code
to illustrate examples, however, the same techniques apply whether the
language is C++, Visual Basic, or some other language).
1) Standards and Procedures
Programming Standards, Naming Conventions, and Procedures should be
set up for the basic elements of programming. For example:
a) all fields in a given file will be named with the first n
characters equal to a defined prefix for one, and only one, file or
table, i.e., MAST-KEY, MAST-NAME, MAST-CUST-NO.
b) all element/data item types will be assigned a standard
abbreviation to always be used for that type, i.e., MAST-ADDR-NO,
ORDR-CUST-NO, INVC-CUST-NO, etc. Items which may occur more than once
should have a serial number attached, i.e., MAST-ADDR-LINE-1,
MAST-ADDR-LINE-2, etc.
c) all input/output procedures for given keys and access types should
be set up as a standard, then called by any program needing to perform
that particular access.
I-O-MAST-OPEN-FILE-IN.
OPEN MASTER-FILE INPUT.
I-O-MAST-OPEN-FILE-OUT.
OPEN MASTER-FILE OUTPUT.
PERFORM I-O-MAST-OPEN-FILE-IN
PERFORM I-O-MAST-OPEN-FILE-OUT
PERFORM I-O-MAST-FIND-KEY etc.
d) files and JCL will use uniform naming conventions such as
<packname>.<env>.<program name>.<filename>
This will improve the quality and accuracy of the software by lowering
the amount of time and expense it takes programmers to understand and
modify a program, or to find a file; and by greatly reducing the
number of bugs resulting from confusion caused by non-standard code;
which will result in happier clients, happier IT staff (because they
are not getting called in the middle of the night and on weekends for
Production problems), and considerably less expense of time and
resources to resolve problems.
2) Test Environment
It is critical to design and set up a Test Environment that mirrors
the Production Environment as closely as possible. A copy of all the
same programs and JCL from the Production should be installed in the
Test Environment. In addition, all the necessary files should be
created here; the file names should be identical, with the exception
of one small indicator that lets a person instantly know whether the
file in question is a Test file or a Production file. One shop at
which I worked used:
<packname>.T01.<program name>.<filename> for Test and
<packname>.P01.<program name>.<filename> for Production.
Any time a program (or set of programs) is modified, the necessary
current Production files should be copied over to the Test
environment, the full JCL for the affected program(s) should be
executed, and a representative number of records on the output file(s)
should be verified for accuracy.
This will improve: quality and accuracy of the software, resulting in
happier clients, happier IT staff (because they are not getting called
in the middle of the night and on weekends for Production problems),
and considerably less expense of time and resources to resolve
problems.
3) Change Control - A system should be implemented to "supervise" the
change process (the moving of programs from Test to Production, and
the prevention of more than one copy of a program being simultaneously
modified for different changes. A good Change Control process will:
a) have an exclusive way to "check out" the program from the Program
Library to a specified programmer. No one else should be able to
retrieve the program's source code for modification while a programmer
already has it checked out. This will ensure that if two programmers
have been assigned to make changes (for two different programming task
requests) to the same program, the second programmer will be forced to
go to the first and work with them to coordinate simultaneous
installation of both changes.
b) prevent just anyone from being able to move programs from the Test
to the Production environment. A form must be filled out, then
approved by an authorizer's signature. For a small shop, only two (or
maybe three) people should have system privileges to move a program
from Production to Test. The authorization forms will then be filed in
some defined manner, so that if problems arise from the change process
later, the form can be retrieved to track -- and fix -- whatever went
wrong.
This will improve: quality and accuracy of the software, resulting in
happier clients, happier IT staff (because they are not getting called
in the middle of the night and on weekends for Production problems),
and considerably less expense of time and resources to resolve
problems.
4) Documentation - I am listing this last, but I believe that it is
probably the most important, so I want to give it special emphasis.
Documentation begins with the written, defined project or program task
request. The analysis stage will produce system summary documentation.
The design stage will produce technical layout and process flow
documentation. The programming stage will produce user documentation.
If rules are not in place to require the documentation as one of the
deliverables for each stage, the documentation will most likely never
happen.
Good Documentation will improve the development of and usage of the
software by lowering the amount of time and expense it takes
programmers to understand and modify a program, and making it easier
for the client to understand and use the software; which will result
in happier clients and happier IT staff because their work is made
easier, and considerably less expense of time and resources trying to
find the answers that should have been included in the documentation.
Before Rating my Answer, if you have any questions, please post a
Request for Clarification, and I will be glad to see what I can do for
you.
Regards,
aceresearcher |
Request for Answer Clarification by
wise_princess-ga
on
17 Nov 2002 14:48 PST
I'm reading The Mythical Man-Month right now, and the author, Fred
Brooks, describes many software engineering principles as applied to a
very large company and a very large project, the development of the
IBM 360 OS in the 1970's. Some of the pitfalls of software engineering
that he describes - e.g. adding more people to a late project just
makes it later (due to increased communication complexity among
groups/departments) - seem to have more relevance to a project that
has many programmers working on it than just 2-3 programmers, as a
small company might have. Thus, this is one methodology that might be
*more* appropriate to a large company than a small company.
So I'm looking for some software engineering principles that might be
more appropriate to small, rapidly-growing company than a large
company. One that I was thinking of is this: A small company might
have an increased need to get software in the beta stage out into
production release quicker, since it may not have an established
foothold in the marketplace already, and could be easily quashed by a
larger competitor. E.g. Microsoft can take all its precious time
getting the next release of Windows out because of its huge customer
base, but a smaller competitor may feel the need to get its features
"out there" to the public faster so that it's not eclipsed by
Microsoft. While this is more of a marketing example than a
software-engineering example, I'm really looking for analogous
software engineering techniques that would *specifically* be applied
to a small, rapidly-growing company and *not* necessarily to a
larger-company.
As far as terminology goes, I guess I'm looking for specific
research-oriented terms to describe the software engineering examples,
and even referenes to IEEE or ACM papers. E.g. instead of "Change
Control", something like "Configuration Management".
|
Clarification of Answer by
aceresearcher-ga
on
20 Nov 2002 06:33 PST
wise_princess,
Here's what I have been able to develop:
1) Configuration Management
According to the Institute of Configuration Management (
http://www.icmhq.com ), the Configuration Management Model "provides
the infrastructure that enables an organization to 'change faster and
document better.'" While this is important for ANY software
development entity, it is perhaps much more critical for smaller
software development entities, because such organizations are
typically much more susceptible to the vagaries of the technology
market.
http://www.icmhq.com/CMII%20Model%20/thecmiimodel.html
While losing a contract (either before a project starts, or after
considerable work has been done and severe problems have arisen) can
be damaging to a software vendor of any size, it is certainly much
more damaging for a small vendor, whose capitalization base may be
much less, thus rendering them much less able to handle a financial
setback.
In addition, one of the advantages of a smaller software development
entity giving them an "edge" over a larger one can be their speed of
responsiveness to defect remediation and product enhancement.
Therefore, it is critical for small software development companies to
have in place strong development methodologies that enable them to
produce quality, defect-free software in the shortest amount of time.
These methodologies include (related to information previously
supplied):
" Requirements Management (Standards & Procedures, Documentation)
Change Management (Change Control)
Release Management (Change Control)
Data Management
Records Management
Document Control (Document Control)
Library Management" (Change Control)
http://www.icmhq.com/CMII%20Model%20/thecmiimodelpg2.html
In order to provide a successful software development methodology,
Configuration Management must be partnered with both:
Project Management
Clear definition of the scope of the project, the expected
"deliverables", and the timeline for the project are required.
Quality Assurance (Test Environment)
A rigorous test process is critical to reduce the incidence of
defects, and the amount of time wasted on remediation, rather than
spent more constructively on product enhancement and new development.
Articles and Opinions on Configuration Management
http://www.icmhq.com/CMII%20Deployment%20&%20Results.html
Configuration Management Today's list of Papers on Configuration
Management:
http://www.cmtoday.com/yp/papers.html
Links to Configuration Management Resources on the Web:
http://www.cmtoday.com/yp/general.html
2) Software Development Knowledge Transfer/Cross-Training
Knowledge Transfer (Cross-Training) is another methodology that is
absolutely critical for small software vendors, which need to avoid at
all costs the "Hit By A Bus" Syndrome.
Large software vendors will typically have several developers who are
knowledgeable about any given segment of the product, and who are able
to step in immediately to fill a hole if necessary.
It is vital that the members of the small vendor's development team be
as interchangeable as possible; that each member is knowledgeable
about the different areas of the software product. That way, if any
one member "walks out the door for lunch and is hit by a bus", the
organization does not grind to a complete halt while existing team
members are re-trained and/or new team members are hired and trained.
"Hit By a Bus The importance of Knowledge Transfer", by Dev Zaborav,
IT World (August 8, 2002)
http://www.itworld.com/nl/unix_sec/08082002
"Using Extreme Programming for Knowledge Transfer", by Luigi
Benedicenti and Raman Paranjape, University of Regina, Canada
Acrobat Reader version:
http://www.xp2003.org/conference/papers/Chapter18-Benedicenti+alii.pdf
html version:
http://216.239.53.100/search?q=cache:pdLKpc83epMC:www.xp2003.org/conference/papers/Chapter18-Benedicenti%2Balii.pdf+small+software+%22knowledge+transfer%22+-%22open+source%22+-%22open-source%22&hl=en&ie=UTF-8
3) Reusable Intellectual Property (IP) Components:
One of the best ways a small software development company can maximize
their programming resources is to institute a strong program for
developing "reusable components". If a standard set of components is
developed for those processes which are repeated again and again
throughout the software, development time can be greatly reduced by
providing programmers the ability to avoid "reinventing the wheel".
Carnegie Mellon's Software Engineering Institute's (SEI) "A Framework
for Software Product Line Practice - Version 3.0"
http://www.sei.cmu.edu/plp/frame_report/produce_assets.htm
I hope this information has provided you with exactly what you needed!
Again, before Rating my Answer, if you have any questions, please post
a
Request for Clarification, and I will be glad to see what I can do for
you.
Regards,
aceresearcher
|
,
0 Comments
)