What is a good program spec?

"When you see a 1:4 ratio of analysts: programmers, is the analysis systems are performing at the wrong time and the wrong person. "
– Bryce's Law

INTRODUCTION

As the industry is interested in producing software faster
(And not necessarily the best), let us pause and consider the typical approach to programming and let me put it in my lap. Basically, there are three aspects to any effort to program development: the definition of program specifications, design and drafting the program itself, and test it. The gurus of software engineering in industry are mainly from the internal design of the program but
is now a series of consultants trying to determine the best way
external program approach. Why? Because there are now many ways to produce software for writing code source using a common text editor, for example, visual programming aids, prototyping tools, workbenches, generators, 4GL programs etc. These tools are the need to write source code specifies the hands of developers and allows them to focus on the basic screen and the presentation of the report. They are excellent tools for programming tasks, but can not do 100% of all programming for all applications. We still need
Developers software professionals with extensive knowledge of programming languages and design techniques. No matter if you write a program manually, or use a type of performer / Generator, we still have to give precise specifications for programmers to do their job.

It is rare that companies will use a uniform approach to development of program specifications. It is not uncommon for developers to receive specifications so dark, like a note from a user (the back of a napkin is my favorite). specifications few consistent data that can be evaluated to be exhaustive. A standard approach to improve productivity and communication within the programming team alone.

What should be in a good program spec? In fact, there is too
difficult to understand …

Elements program specification A

Each program must be defined in terms of:

1. Description of entry (to collect data or seek an exit) – that is implemented through a graphical interface, the command line interface, verbal display, optical or other interfaces. All nominations should include:

   a. Name, alternate ID, Label Program, description.
   b. design and examples given.
   C. specification for transaction entry, including default values
   control standards and data collected.
   d. The messages, for example, data validation, and general management.
   e. Panels (For display).
   f. Relationship between resources and results.

2. Showing out (to retrieve the data) – whether performed by a GUI report printed, audio / video interface or other display. All outputs should include:

   a. Name, alternate ID, Label Program, description.
   b. set design and examples.
   C. Panels (for screens), maps (for reports).
   d. Messages treatment For example, the general and specific program
   Messages information, warning and error.

3. Data Structure Descriptions (databases, files, records and data elements).

   NOTE: Programmers should not be in a design
   databases that are going to do what is convenient for their
   implementation, others do not (losing the opportunity for
   company sharing and reuse of data). Physical files should be defined by the database administrators.

   a. All data structures must include: Name, ID alternative
   Label Program, description. It should also include …
   b. Databases – the organization, key (S), the labels, the volume and size
   backup requirements, internal structure.
   C. Files (two primary and working) – the organization, word (s)
   labels, the volume and size, backup requirements, internal structure,
   file file relationships.
   d. Records – shape, length, word (s), content, one record to another
   relationships.
   e. Data elements – class, justification, a fill character,
   vacuum state, fashion, photography, etiquette, size, precision, scale,
   validation rules. If the processed data, rules of calculation.
   If the data standards group assignment.

4. Program Description:

   a. Name, another number identification tag program description.
   b. Characteristics: processing speed necessary memory requirements.
   C. Units other external programs (eg, batch stream).
   d. Dependencies to internal modules (eg, DLL, subroutines, etc)
   e. Functions to be carried out with inputs, outputs and
   Data Structures (create / update / reference).
   f. Special rules for processing (processing logic)
   g. command language needed to run the program (eg, command files, JCL, etc)
   h. The environment physical running the program.
   i. Test plan and how test data collection.
   j. Method of execution – Programming language (s)
   use technical design to meet, the tools
   used.

Internal standards in software engineering and specifications to complete the program (and should provide guidelines for writing specifications). These rules define "best practices" for design and conventions for the programming. Incidentally, the software engineering goal should be: Maintainability (easy to correct and update) performance good design (the test), international support (To accommodate the languages and cultures), integration (the sharing and reuse of code) and portability (Platform independence).

Among the programming specifications as described above and a good set of programming standards, it becomes fairly easier to implement a program either by hand or by a generator. As a matter of policy, the specifications should be written under the assumption that a generator program is used. This forces us to be more precise in our specifications.

Okay, so how come?

When assembly is a specification of the program, I am of the philosophy that "You eat elephants one spoonful at a time." It is difficult to gather the characteristics of a single program in a single blow. Moreover, if we consider most development projects today, more than one program, the problem becomes more complicated. For major development efforts, I believe that "slices" of the documentation required. For example, under the title "PRIDE-ISEM, consider a system as a set of subsystems (Business Process), implemented by procedures (administrative and IT), administrative procedures cover the steps (tasks), and consist of software procedures (which may be sub-divided into modules, if desired).

Basically, "Pride" a system of views as a product that can be designed and manufactured like any other product. From this point of view, we can engineer others as a top-down approach to documentation Blues where levels of abstraction for defining the different levels in the hierarchy of the system. For example, phase 1 reporting requirements contained in the study "Assessment Systems Manual" to define which system (s) are needed (either new or existing systems requiring a change), Phase 2 "System Design" Manual includes specific subsystems, Phase 3 "Sub-System Design Manual" specifies procedures
business processes, stage 4-I "Administrative Procedure Manual" specifies the operational measures, and Stage 4-II "by Team library "indicates the programs. This approach allows us to make plans to progressively improve our specifications to reach the bottom of the product structure. In other other words, it is necessary to define any input, output, files or data item at a time, but rather to first identify the need for them then gradually refine the details until we are ready for programming.

This approach to documentation is sometimes referred to as the "Refinement Step step "that the design of a structure, as a product or construction, is refined at different levels of abstraction. Only when we finish these architectural
designs can transport the products to manufacturing and construction. Imagine trying to build a car or a skyscraper, but such a technique. It would be virtually impossible. Why systems be? In order that this approach
work, you must accept the concepts of a system is a product there are different levels of abstraction, and there are standards for documentation of each level. This is considerably different from the approach "based on forms for development;
For example, filling out forms in a regimented sequence without a second thought on the design of the system. Instead, the documentation should be a natural byproduct the design process.

This also clearly defined in terms of "types" of specifications, such as reporting requirements "And" information programming "is miles away in terms of content and purpose. While the former is a specification for the operational needs the user, is a technical specification
for the programmer to implement.

Blues's approach also emphasizes the need for basic systems work in the first stages of design, programmers be the beneficiaries of more detailed specifications (as opposed to vague concepts), which
simplify work.

CONCLUSION

So what is a good program spec? All that takes the guesswork for the programmer. Consider this: if the system works to advance the design was done right, programming should be less than 15% of the development process. Why is currently control 85% of our time together (and money)? Mainly because we have changed our focus and do not believe we are more productive if we
programming. After all, programming is perhaps the most visible evidence of our work effort, system design is less tangible.

Let me illustrate, 1976 I took a training entry-level IBM COBOL in Cincinnati. Our class was divided into three teams and each team had problems to solve. When we receive an assignment, the other two developers on my team immediately started to write code
their key inputs (Yes, we have used the exercise equipment at the time), then compile the program. Inevitably, mistakes were made and they come and go until you correct the mistakes made no mistake. As for me, when I got a mission, I would like a model of plastic and paper, and work on the logic of the program before writing the code. Then I press and compile, and always finish the job before my classmates. Curiosity got the better of me and I asked, "Why so?" They argued that as they were called to work by his superiors, were not productive if they were production code. I replied that although they were faster in the production of code, still beats ever, simply because I thought the problem through.

IBM Representative, I enrolled in the class that came to stop and asked me if I was to learn something. I said I was learning more about programmers "that I was" programming. "I'm still learning about the programmers, but not I noticed no significant change in their attitudes
to the development since then. Of course, we now have powerful tools to speed programming. But if so good, why not reduce our delay? Why are we constantly in maintenance mode? Why do not we think of our applications never complete principal on time? Why? Because we do in that job.

Remember, it is always "Ready, Aim, Fire" – any other sequence is simply counter-productive.

About the Author

Tim Bryce is the Managing Director of M. Bryce & Associates (MBA) of Palm Harbor, Florida, a management consulting firm specializing in Information Resource Management (IRM). Mr. Bryce has over 30 years of experience in the field. He is available for training and consulting on an international basis. His corporate web page is at:

http://www.phmainstreet.com/mba/

He can be contacted at: timb001@phmainstreet.com

Copyright © 2006 MBA. All rights reserved.

Cincinnati #5 Vertical Milling Machine In Superb Condition