CS302: Software Engineering (2021.B.01)

Status Monitoring and Reporting 

The rationale of the planned application development is that you monitor the plan to communicate activity status and interim checkpoints to clients. The overall goal-meeting the project installation date-is the end point of a lengthy complex set of processes. Without the plan, knowing whether or not the installation date will be met is difficult. Status monitoring is the comparison of planned and actual work to identify problems. Project control is the decisions and actions taken based on the project's status. 

In a planned approach, project team members report time spent on each activity for some period. The sample timesheet (see Figure 3-7), allows breakdowns for several tasks listed across the top of the form and hours worked on the task reported by day of the month. Totals by day of the month and by task over the period are tallied by row and column totals. This type of reporting allows the project manager to easily see for each person weekend work, how many hours are spent on each activity over a period, and how many effective work hours there are per day. 

In addition, each person should write a short progress report. The report summarizes progress in qualitative terms, identifies problems, issues, errors, or other conflicts that might delay the work. If a task will be completed later than its scheduled date, the reason for lateness must be explained. The project manager and SE both review the reports and time sheets to decide if problems need further action. A sample progress memo is shown as Figure 3-8.

The SE and project manager map actual progress of each person against the planned times. When progress looks slow, the project manager asks the person specifically if there are problems, if there are enough resources, for example, test shots, and if the person thinks they can meet the deadline. If the task appears to have been underestimated, the schedule is checked to see if changing the time allotted will cause completion delays. Similar tasks are checked to see if they are also underestimated. The cumulative effect of changes is checked to see if completion is in jeopardy. If it is, the project manager discusses the problem with his or her manager and they decide on the proper course of action. 

The best policy is to address potential problems early, before they become big problems. If a person cannot finish work because of too many assignments, then reassign some of the work to another person. If they have not got enough testing time, arrange for more time. Active management prevents many problems.

Problem follow-up includes determining the severity and impact, planning an alternative course of action, modifying the plan as required, and continuing to monitor the problem until it is resolved or no longer has an impact on the delivery date. 

Tell the client about problems that may not be solved so they are prepared for delays if they become inevitable. When changes become needed, tell the client about changes to planned dates even when they do not change the completion date.

Project:  ____________________ Month:  __________________ Name:  _____________________   Activities Day of Month             Total  for Day 1/16               2/17               3/18               4/20               5/20               6/21               7/22               8/23               9/24               10/25               11/26               12/27               13/28               14/29               15/30               31               Total

FIGURE 3-7 Time Sheet

ICIA Industries—Interoffice Memo TO:              J. B. Berns DATE:        October 10, 1994 FROM:        M. Vogt SUBJECT:  Order Entry and Status   Progress   We completed our screen design and navigation testing 10/7/94 and turned the modules over to George Lucas for user acceptance. He requested changes to several items: 1.      The location of the total at the bottom of the screen is moved left five spaces. 2.      The PF key assignment for PF3, which we were using to END any process. He would like END to be PF24. We explained that this is not a good design because the operator needs more keystrokes (and hence is more likely to err) for PF24. Also, this is a very time-consuming change, about 10 hours, and that he should have mentioned his preference during the reviews. He decided to think about it and talk to some real operators before making a firm decision. The other testing is progressing well. I am almost done testing the entire order process, except for inventory allocation. I need the warehouse codes from George by next week if I am to continue testing the programs. Problems The warehouse codes which were promised some months ago are getting to be on the critical path. If I do not have them by next week, I cannot continue to test the inventory allocation portion of the application. I can assign my own code scheme, then change it to the real one if I have to, but I would like to avoid the double work.

FIGURE 3-8 Sample Progress Report

The kinds of problems that occur and the activities the project manager monitors change over the course of the development. For instance, during the definition of the project scope, the project manager monitors the following:

Is the client cooperative? 

Are all the stockholders identified and involved?

Are users being interviewed giving accurate, complete information? 

Are users participating as expected? 

Are there any apparent political issues to be addressed? 

Does the scope look right? That is, does the current definition appear to include relevant activities?

By analysis, the project manager knows most users and how they work, should have identified potential political problems and dealt with them, and should be comfortable that the project scope is correct. The activities monitored turn toward the project team, and include the following:

Do all analysts know the scope of activity and work within it?

Is the analysts' work emphasis on what and not how?

Are users participating as expected?

Are all project members pulling their weight?

Is everyone interested and happy in their job?

Is there any friction between team members, or between team members and users?

Does everyone know what they and all others are doing?

Is there constant feedback-correction with users on interview results?

Are team members beginning to understand the users' business and situation? Are the team

members objective and not trying to force their own ideas on the users?

Are walk-throughs finding errors and are they getting resolved?

Are documents created looking complete? Does the user agree?

Is the analysis accurately addressing the problems of the user? Are team members analyzing and describing exactly what is needed

without embellishment?

Is typing turnaround, printing of word-processed documents, copying, or other clerical support acceptable?

Does communication between teams and between teams and users appear to be satisfactory?

Is the project on time? What is the status of critical path tasks? Has the critical path changed because of tasks that finished early?

Where are the biggest problems right now? How can we alleviate the problems?

What do we not know that might hurt us in design?

The functional requirements that result from analysis should describe what the application will do. The project manager is constantly vigilant that the requirements are the users. One problem many projects have is that the user wants a plain functional application but the analysts design a high-priced application with the user functions, but with many unnecessary features, or 'bells and whistles,' as well. This problem, if it occurs, must be dealt with before analysis ends or extraneous functions will be in the resulting application. When over-design problems surface, it is important to try to trace them to specific analysts for retraining in providing their services. 

In design, the emphasis shifts to monitoring the rate, type, and scope of changes from the users. If the business is volatile, requirements change may become a constant problem. Change management procedures should be developed and used. At this point, the project manager's worries include the following:

Do the analysts know the application?

Is the transition to an operational environment correct and complete?

Are walk-throughs finding errors? Are errors being resolved?

Are users participating as expected? Are users properly involved with screen design, test

design, acceptance criteria definition?

Are all project members pulling their weight?

Is everyone interested and happy in their job?

Is there any friction between team members, or between team members and users?

Does everyone know what they and all others are doing?

Are all team members aware of their changing responsibilities, and are they comfortable

with and able to do design tasks?

Does communication between teams and between teams and users appear to be satisfactory?

Is the project on time? What is the status of critical path tasks? Has the critical path

changed because of tasks that finished early?

Where are the biggest problems right now?

How can we alleviate the problems?

What do we not know that might hurt us in programming? Is the implementation environment suitable for this application? 

Can the database management software accommodate this application?

The number of project team members usually increases for programming to do parallel development as much as possible. The communication overhead necessary to know everyone's status and for them to know the project status increases. The problems in the programming and unit testing stage tend to focus on communications and programmer performance.

Does everyone understand how their work fits into the project? Does everyone know their

critical-path status? Are all current project members pulling their weight? Does everyone know what they and all others are doing?

Is testing time sufficient? Is terminal access sufficient?

Does everyone know the technologies they are using sufficiently to perform independently?

Are junior staff paired with senior mentors?

Are users requesting further changes?

Are users participating as expected in test design, user documentation development, conversion, and training?

Is there constant feedback-correction with users on suspected errors?

Are prototypes being used as much as possible to demonstrate how the application will work?

Are walk-throughs productive, finding errors? Are errors getting resolved?

While programming and unit testing are proceeding, tests for integration and system level concerns are being developed. The database is being established and checked out. The operational environment is being prepared. Concern shifts from getting the application expressed in code to getting it working correctly. The kinds of questions a project manager might have are the following:

Are all current project members pulling their weight? Does everyone know what they and all others are doing?

Is testing time sufficient? Is terminal access sufficient?

Are users requesting further changes? Are users participating as expected in testing? 

Is there constant feedback-correction with users on suspected errors?

Are walk-throughs productive, finding errors?

Are errors getting resolved?

Does the system level test really prove that the functions are all accounted for?

Does the integration test verify all interconnections? How can it be leveraged to prove the reliability of the interconnections during the system test?

What do we not know about the operational environment that might hurt the project?

Is the database software working properly? Are back-up and recovery procedures adequate for testing?

How can we use the integration and system tests to develop a regression test package?

Is documentation being finalized? Is everyone working to capacity? Should we start letting programmers go to other projects? If we let a key person go, who can take their place when a problem occurs? 

Finally, testing is complete, the application appears ready, and the user is ready to work. There should have been a plan for actually implementing the operational application that eases the user into use without too much trauma. The easing-in period gives the project team some time to fix errors found in production without excessive pressure. The issues now center on getting the application to work in its intended environment for its intended users. The questions include the following:

Is the site prepared adequately? Is air conditioning sufficient? Are lighting and ergonomic design sufficient? 

Are users properly trained and ready to do work? 

Are work cycles and evaluation of results identified sufficiently to allow implementation and verification of results? 

When errors are found, are they getting resolved? 

Are users taking charge as expected? 

Are all current project members pulling their weight? Does everyone have enough work to do? Can people be freed to other projects?

Is communication between teams and between teams and users appearing satisfactory? Are users told whenever major problems occur? Are they participating in the decision making about error resolution?

Many of the questions above are technical in nature and would be referred to the SE to monitor. The project manager is like a mother hen and is supposed to worry about everything. Obviously, if the plan addresses the activities as it should, many of the answers to the above sets of questions are found in weekly progress reports of team members. Compiling the individual progress reports and project progress reports in a project log allows the manager and any of the staff to review decisions, problems and their resolutions, and other issues as they occur during the development.