Management documents

10.1 Management documents

Every software development project is going to be managed in some way. A plan will be prepared, in one form or another, that lays out the expected schedule and resources. Effort will be expended to review and test the software, at least at the end before delivery, and the components of the software will be identified so that the delivered software and its components are known.

The following management documents are common to all software development projects:

• 
  

  Software development plan;

  
  


• 
  

  SQS plan;

  
  


• 
  

  CM plan.

  
  

These documents are the overall software development process control documents. Their size and depth of detail will vary with the size and complexity of the system being developed. They may even be merged into a single document for small projects. Even so, the content, describing how the development project will be managed and controlled, must be present for each software development project. It should not be surprising that the more formal the planning and its documentation, the more complete and effective it will be. Thus, the creation of the software development plan (SDP), the software quality system plan (SQSP), and the configuration management plan (CMP) is a necessary part of each software development project.

These plans for a project leading to 500,000 or more lines of code would probably cost more than a whole 500-line project. Therefore, the level of detail and control included in each plan must reflect the size and complexity of the project at hand.

10.1.1 Software development plan

The SDP is the document that lays out the management approach to the software project. In its most basic form, the SDP will include the schedule and resource needs for the project. The milestones for tracking the progress of the project will be specified, probably as a pictorial of the SDLC. The personnel loading will also be shown so that the required expertise and skills can be available when they are needed. The SDP should also specify hardware and environmental needs such as computer time, special test facilities, compilers and linkers, other systems, and the like.

For simple systems, the material covering the SQS and CM may also be included as separate sections in the SDP. As system complexity grows, so does the SDP. More and more detail is required to cover the larger scale of the software development activity. Schedules must contain intermediate checkpoints or milestones, and personnel loading will become more varied and complicated. Test support facilities will become more elaborate. The SDP will also begin to address software quality and CM to a level of detail that precludes their inclusion as SDP sections.

The more elaborate the software system, the more it probably interfaces with other systems and the outside world. While these interfaces are presented in requirements documentation, provision for their involvement in testing must be ensured and scheduled in the SDP.

Larger systems may require enough people or facilities to justify special offices or test laboratories. If so, these must be presented in the SDP so that their availability is ensured.

Budget control becomes more important as the size of the system grows. The SDP is the appropriate place to present budget considerations and to specify control mechanisms in support of the normal, companywide costs accounting system.

While the software quality practitioner obviously does not generate the SDP, the practitioner has the responsibility for reviewing it against SDP standards and ensuring that all appropriate information is present. Deficiencies detected both by the software quality practitioner and any other SDP reviews should be corrected before the project is permitted to commence.

The software quality practitioner also monitors the software development activities against the SDP. Deviations are reported so that corrective action may be taken by management.

Most corrective action will be to correct the software development process where it has strayed from the plan. Some corrections will be made to the SDP to keep it current with changes in the project. The software quality practitioner will review these changes to ensure that contracted requirements are not being violated and that the plan still complies with the standards for it.

See Appendix A for a sample SDP outline.

10.1.2 SQS plan

The SQSP addresses the activities to be performed on the project in support of the quest for quality software. Being careful not to exceed the requirements of the customer, company standards, or the SDP, the SQSP will discuss all of the activities to be performed on all of the various SLC products. A sample format for an SQSP is shown in Appendix B.

Remember that a software quality group is not necessary for the SQS functions be performed. Thus, the various software quality functions will be assigned, through the SQSP, to be the organizational entities that will perform these functions. All activities to be accomplished in the software quality area should receive the same personnel, resource, and schedule discussion as in the overall SDP, and any special tools and methodologies should be discussed. The SQSP may be combined with the CMP (see Section 10.1.3) for medium-sized efforts.

Whatever the format of the SQSP, it is important that the document (or its information if in another document) be complete and approved by management and the producers. The SQSP becomes the charter for the SQS functions for the particular project when approved by management. It lays out the entire SQS and how it will be implemented.

Without the involvement of and approval by the software developers, the SQSP can be a recipe for ineffectiveness and frustration on the part of the software quality practitioners. Without the cooperation of the developers, software quality practitioners can be severely hampered in their attempts to conduct the review and monitoring activities for which they are responsible. Involving the development organizations in the generation and approval of the SQSP can encourage their cooperation as the project progresses.

The software quality practitioners must also monitor their own plan and their activities according to the plan. Any deviation from the plan or any indication that it is inadequate must be corrected. The software quality practitioner will monitor all the software management and development activities. It is certain that management and the developers will be watching the software quality practitioners to be sure they perform according to the SQS plan, the whole plan, and nothing but the plan.

10.1.3 CM plan

CM, as discussed in Chapter 6, is a threefold discipline. Each of the three activities should be discussed in its own section of the CMP. The methods, requirements levied on the producers, contracted requirements, and tools to be used for software CM all should be spelled out. (See Appendix C for a sample format for a CM plan.)

If the project is small, the necessary information may be included in the SDP. On medium-sized projects, it may be appropriate to combine the CMP information with the SQS plan in a single, dual-purpose document.

While some of the information may be in the personnel and resource sections of the SDP, CM-specific information must be presented in the CMP. Schedules for baselining, major reviews, and auditing should be shown either on the overall project schedule or on the CM schedule.

Any special tools or resources needed to support CM must be called out in the CMP. Another topic that may appear in the CMP is the operation of the software development library, which is the depository of all software product master copies. If not discussed elsewhere (e.g., SDP or SQSP), the library, its responsibilities, functions, and so forth should be presented in the CMP.

As with the SDP, the software quality practitioner has the responsibility to review the CMP before its release and adoption. The software quality practitioner should ensure that the CMP is complete and appropriate for the project and that it meets any specified format and content standards.

Software quality practitioners will also review the CM activities on an ongoing basis. The reviews will ascertain whether the activities described in the plan are being performed and if they are still appropriate for the project.

10.1.4 Additional plans

As software becomes an increasingly critical part of our lives, additional plans may be required for some software system development efforts. Such plans might include the software safety plan (Appendix K) and the risk management plan (Appendix L). These plans are certainly not required for all development projects. It is the responsibility of the quality practitioner to evaluate their necessity for each new project and to recommend their preparation when appropriate.

Section 1.9.  Signals

1.9. Signals Signals are a technique used to notify a process that some condition has occurred. For example, if a process divides by zero, the signal whose name is SIGFPE (floating-point exception) is sent to the process. The process has three choices for dealing with the signal. Ignore the signal. This option isn't recommended for signals that denote a hardware exception, such as dividing by zero or referencing memory outside the address space of the process, as the results are undefined. Let the default action occur. For a divide-by-zero condition, the default is to terminate the process. Provide a function that is called when the signal occurs (this is called "catching" the signal). By providing a function of our own, we'll know when the signal occurs and we can handle it as we wish. Many conditions generate signals. Two terminal keys, called the interrupt key often the DELETE key or Control-Cand the quit keyoften Control-backslashare used to interrupt the currently running process. Another way to generate a signal is by calling the kill function. We can call this function from a process to send a signal to another process. Naturally, there are limitations: we have to be the owner of the other process (or the superuser) to be able to send it a signal. Example Recall the bare-bones shell example (Figure 1.7). If we invoke this program and press the interrupt key, the process terminates because the default action for this signal, named SIGINT, is to terminate the process. The process hasn't told the kernel to do anything other than the default with this signal, so the process terminates. To catch this signal, the program needs to call the signal function, specifying the name of the function to call when the SIGINT signal is generated. The function is named sig_int; when it's called, it just prints a message and a new prompt. Adding 11 lines to the program in Figure 1.7 gives us the version in Figure 1.10. (The 11 new lines are indicated with a plus sign at the beginning of the line.) In Chapter 10, we'll take a long look at signals, as most nontrivial applications deal with them. Figure 1.10. Read commands from standard input and execute them #include "apue.h" #include <sys/wait.h> + static void sig_int(int); /* our signal-catching function */ + int main(void) { char buf[MAXLINE]; /* from apue.h */ pid_t pid; int status; + if (signal(SIGINT, sig_int) == SIG_ERR) + err_sys("signal error"); + printf("%% "); /* print prompt (printf requires %% to print %) */ while (fgets(buf, MAXLINE, stdin) != NULL) { if (buf[strlen(buf) - 1] == "\n") buf[strlen(buf) - 1] = 0; /* replace newline with null */ if ((pid = fork()) < 0) { err_sys("fork error"); } else if (pid == 0) { /* child */ execlp(buf, buf, (char *)0); err_ret("couldn't execute: %s", buf); exit(127); } /* parent */ if ((pid = waitpid(pid, &status, 0)) < 0) err_sys("waitpid error"); printf("%% "); } exit(0); } + + void + sig_int(int signo) + { + printf("interrupt\n%% "); + }

7.2 FREQUENCY DIVISION MULTIPLEXING

< Day Day Up >

---

7.2 FREQUENCY DIVISION MULTIPLEXING

In frequency division multiplexing (FDM), the signals are translated into different frequency bands and sent over the medium. The communication channel is divided into different frequency bands, and each band carries the signal corresponding to one source.

Consider three data sources that produce three signals as shown in Figure 7.2. Signal #1 is translated to frequency band #1, signal #2 is translated into frequency band #2, and so on. At the receiving end, the signals can be demultiplexed using filters. Signal #1 can be obtained by passing the multiplexed signal through a filter that passes only frequency band #1.

Figure 7.2: Frequency division multiplexing.

FDM is used in cable TV transmission, where signals corresponding to different TV channels are multiplexed and sent through the cable. At the TV receiver, by applying the filter, a particular channel's signal can be viewed. Radio and TV transmission are also done using FDM, where each broadcasting station is given a small band in the frequency spectrum. The center frequency of this band is known as the carrier frequency.

Figure 7.3 shows how multiple voice channels can be combined using FDM.

Figure 7.3: FDM of voice channels.

Each voice channel occupies a bandwidth of 3.4kHz. However, each channel is assigned a bandwidth of 4kHz. The second voice channel is frequency translated to the band 4–8kHz. Similarly, the third voice channel is translated to 8–12 kHz and so on. Slightly higher bandwidth is assigned (4kHz instead of 3.4kHz) mainly because it is very difficult to design filters of high accuracy. Hence an additional bandwidth, known as guard band, separates two successive channels.

In FDM, the signals from different sources are translated into different frequency bands at the transmitting side and sent over the transmission medium. In cable TV, FDM is used to distribute programs of different channels on different frequency bands. FDM is also used in audio/video broadcasting.

FDM systems are used extensively in analog communication systems. The telecommunication systems used in telephone networks, broadcasting systems, etc. are based on FDM.