CEN 4021 Software Engineering II

1. CEN 4021 Software Engineering II Monitoring (POMA) Instructor: Masoud Sadjadi http://www.cs.fiu.edu/~sadjadi/ sadjadi@cs.fiu.edu

2. Acknowledgements • Dr. Onyeka Ezenwoye • Dr. Peter Clarke

3. Agenda • Monitoring (POMA) • Monitoring • Overview of Project Monitoring • Data gathering and Monitoring

4. Project Monitoring • The regular collection of project information that is considered relevant to the measurement of the goal attainment. • The analysis and evaluation of the collected information. • The presentation and communication of the information related to project status to the project team members, upper management, and potential customers • Making projections and recommendations based on the analysis of the data.

5. Formal Data Gathering and Monitoring • Formal gathering of project information is usually performed at regular intervals such as daily, weekly, or monthly depending on the type of activity and the stage of the project. • For example, information on project status may be collected on a weekly basis during the requirements gathering and analysis phase, but on a daily basis during functional testing phase. • The frequency of data gathering may also depend on the urgency of the activity.

6. Formal Data Gathering and Monitoring • For example, support manager may collect customer problem reporting at the end of each day; however, a high-priority customer problem may require problem reporting on an hourly basis. • The data collection may also be based on project activities or on some project attribute. • Both activity-based and attribute-based methods may be employed for measuring schedule goals.

7. Formal Data Gathering and Monitoring Activity-based monitoring: • Consider the requirements gathering and analysis phase, assume information is gathered on a weekly basis. • The activities include requirementsinterview, requirementsdocumentation. • The data desired in this case are non-numeric, i.e., the data collected are yes or no depending on whether the minor milestone is or is not met.

8. Activity Completion Status

9. Formal Data Gathering and Monitoring Activity-based monitoring: • The actual representation of the data collected, in the date format, contains additional information e.g., the number of days before or after the expected completion data of the activity. • This type of data collection is activity-based in that the team is collecting attribute information i.e., completion dates, about the activities. Note also that with this type of information collection, more than logical values, one can perform arithmetic manipulation and obtain derived data.

10. Formal Data Gathering and Monitoring Attribute-based monitoring: • Consider the screen requirements prototyping task. It is not enough to give a simple yes/no answer regarding the completion of the prototype. • In this case the data collected is based on an attribute e.g. the number of panels that have been developed, shown to the users, and approved by the users. • This type of data collection is attribute-based i.e., the team picked an attribute and the frequency to assess the result of the activity.

11. Date Attribute-based Status

12. Levels of Monitoring • Generally activity-based data collection would apply better at a “macro” level i.e., we list only those activities that are considered to be at least minor milestones. • Attribute-based data collection would be a better fit for a “micro” level of data collection, in that we will collect the smallest unit of the attribute.

13. Levels of Monitoring • The major goals and measurements for software projects: • Schedule integrity • Completeness of function • Quality • Budget Completeness of Function • An attribute of a software product that describes the number of features implemented versus the number required for the product.

14. Levels of Monitoring • Attribute-based monitoring • The completeness of attributes may be viewed in more detail by subdividing each feature into the categories: basic, intermediate and advanced. • The table shown above allows the project team to collect and record information indicating how much of each feature is completed for each functional requirement. • The functional attribute-based data collection mechanism facilitates the detail counting of the features, so it serves the manager well at the micro level.

15. Function Attribute Completeness Monitoring

16. Levels of Monitoring • Activity-based monitoring • At the macro level, manager may want to collect information on project activities completed. • The activities would be the process tasks that contribute to the production of the desired functions. • The activity-based data collection method indicates where each function is in terms of the activities that must be performed. • The direct data collection give the team a global picture of the status at the different activity levels.

17. Software Process Activity-based Monitoring

18. Levels of Monitoring Monitoring Quality • An attribute of a software product that describes how well the product satisfies and serves the needs of the users. It offers a broader view of quality than the attribute that addresses only the defects in the product. • Attribute-based monitoring • Consider one possible goal of quality: to achieve the level where there is no known severity level 1 problem in the product prior to its release. • Assume that the different severity levels have already been defined.

19. Function Attribute-based Quality Monitoring

20. Levels of Monitoring • Attribute-based monitoring • Consider one possible goal of quality: to achieve the level where there is no known severity level 1 problem in the product prior to its release. • Assume that the different severity levels have already been defined. • The Table above shows the data being gathered just prior to the software product’s release. The metric for the quality goal is the number of severity level 1 problems. • The team collects data based on the quality attribute of each functional area at release time.

21. Levels of Monitoring • Activity-based monitoring • The results for activity-based monitoring looks a lot like the activity-based data collection for completed functions. • Suppose the activities list is based on the sequence of defect detection and removal activities that will be performed as part of the s/w project. • Table 9.6 shows the defect identification and removal activities for severity 1 problems. Note in most s/w projects all levels of problems found and fixed are collected and tracked. (Go through table 9.6)

22. Defect removal activity-based quality monitoring

23. Levels of Monitoring • The attribute-based and activity-based data collection mechanisms are very similar for the monitoring of s/w quality. Both provide the global view of the quality status of all the functions. • The attribute-based data collection mechanism may be easily expanded to include lower severity levels, and it can achieve a more detailed view of quality by functional area.

24. Levels of Monitoring Monitoring the Budget • An attribute of a software project that describes the financial resources allocated and expected to be followed, by some time period such as monthly or quarterly and by areas such as tools, people, travel, or education, for that project. • Usually managed at a higher level than first-line project managers’ level. • Some organizations include the managers in the discussion of the budget. • Managers may need to be aware of the cost of features

25. Levels of Monitoring • Attribute-based monitoring • Budget related data may be collected with the attribute-based methodology as well as the activity-based method. • Table below shows one possible attribute-based data collection method. • The items that go into each table entry must have been planned and prepared during the planning and organizing/preparing phases.

26. Function Attribute-based Expense monitoring

27. Levels of Monitoring • Attribute-based monitoring • An expense entry for each software function includes costs for the following resources: • People • Tools • Travel • Special education • General overhead (office space, phone service, desktop computer, and so on) • If a particular function is an acquired function, then the expense for it may be spread out in an even fashion over the time interval.

28. Levels of Monitoring • Attribute-based monitoring cont • Some lump-sum expenses incurred at the beginning of a project may cause the project to temporarily show an expense overflow. For example, the purchase of licenses for a s/w tool. • Activity-based monitoring • Table 9.8 shows an example of activity-based expense and revenue modeling. • Provides a global view of the expenses of all functions as each function goes through each of the activities.

29. Levels of Monitoring • Activity-based monitoring cont • For each activity, the preparation for the measurement must be established by working with the financial organization. • project managers must collaborate with the financial organization during the planning phase as well as the organization and preparation phase. • There may also be a need to reserve the services of a person in the accounts department to spend some time collecting data. • As a consequence, the data collection expense may be charged to the project as an activity itself.

30. Data Collection Schedule • Formal collection of data for the purpose of project monitoring should be performed on a regular basis. • The frequency of data collection is usually based on the size of the project. • Data collected throughout the project should be maintained for historical purposes. • Using this historical data may be used to tune the parameters used in the estimation of cost and time for future projects.

31. Status Meetings • Formally collected data should be presented by the project team members to their colleagues at regular project status meetings. • Purposes of project status meeting: • A means to collect the data, and • A way to communicate those data • Note that time spent in meetings and data collection is indeed time taken away form the direct project development. • Automation and tools may be one answer.

32. Status Meetings • Data collection automation/tools • Information from various stages of the s/w development process may be collected as more automation is introduced. • Borland’s Togethersoft is used to develop a design and code for the project. The same tool can provide information on how many objects, modules, or lines of code have been developed. Any other tools? • Formal project status meeting: • Meetings should not be too long, should be less than 10% of the work week.

33. Status Meetings • Formal project status meeting cont: • Key personnel (managers and project team leaders) are likely to attend meetings. • If any data require additional discussion a separate meeting should be scheduled. • Watch out for “surprise” items, i.e., items that take on a life of their own. • The project manager should be disciplined enough to log surprise items onto the list of high-risk items and immediately a separate session should be scheduled. • Key attendees should not be allowed to send substitutes.

34. Status Meetings • Formal project status meeting cont: • Meetings are usually well attended at the beginning of a new software project. Attendance problem tends to appear later in the project. • The key to an effective formal status meeting is to create an agenda and stay within its bounds, scheduling any subsequent and additional meetings if necessary to cover off-agenda items. • The agenda should be circulated prior to the meeting so that all the attendees are aware of the topics to be covered and the time allotted for each topic.

35. Status Meetings • Formal project status meeting cont: • Each time slot should include a small buffer to allow for extra discussion on a topic. What is on the agenda? • Agenda items need to be correlated with the project goals, i.e., attaining those goals is mainly what is under review. • Sample s/w project status meeting may have the following parts: • Review of the project and product progress metrics: schedule, items completed, cost, defects discovered and corrected, and so on.

36. Status Meetings • Review of personnel and resources: problems, rewards, and so on • Review of risk items: number, status, and so on • Review of any other items: customer status, industry status, and so on. • project managers need to keep in mind that while project monitoring may be the most important item for managers, other team members are equally driven to complete their tasks, usually not related to management per se.

37. Informal data gathering and monitoring • S/w projects depend heavily on the performance of people. Human performance is based on some hard-to-get information e.g.: • A false rumor • A particular tool not working • A process that is viewed as bureaucratic may be circumvented • A key employee seeking other opportunities and getting ready to resign from the project. • project managers need to perform conscientious socializing.

38. Informal data gathering and monitoring • project manager should perform the following to keep the informal line of communication open: • Keep the management offices “open” • Make daily walks and visits to the team members’ offices. • Invite team members to the project manager’s office to chat about the project. • Have scheduled “lunches” with different, small groups of team members. All of the above requires some physical contact.

39. Informal data gathering and monitoring • Physically remote environment • Many project managers have virtual meetings instead of person-to-person contact. • Virtual meeting are held through phone, video conferencing, or bulletin boards. • If project team members are located at remote sites then the project manager needs to make a special effort to meet them in person when they start the project. • Establishing trust • The project manager must work to gain the trust of the members on the project team.

40. Informal data gathering and monitoring • Establishing trust cont • The project manager must work to gain the trust of the members on the project team. • If a team member trust the project manager it is easier to obtain the informal information (i.e., his/her true feelings regarding the project) that can be very valuable to managing the project. • Trust must be earned and it takes time to establish. • Trust is a mutual activity and must be honored on both sides. • Note that some information must never be shared, e.g., employee’s personal information.