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

2. 14 th LectureCEN 4021: Software Engineering II Acknowledgements  Dr. Onyeka Ezenwoye  Dr. Peter Clarke 2

3. 14 th LectureCEN 4021: Software Engineering II Agenda  Monitoring (POMA) –Monitoring  Overview of Project Monitoring  Data gathering and Monitoring

4. 14 th LectureCEN 4021: Software Engineering II 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. 14 th LectureCEN 4021: Software Engineering II 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. 14 th LectureCEN 4021: Software Engineering II 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. 14 th LectureCEN 4021: Software Engineering II 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 requirements interview, requirements documentation.  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. 14 th LectureCEN 4021: Software Engineering II Activity Completion Status Milestone activitiesExpected completion Actual Completion Delta Requirements interviews07/05/200307/10/2003+5 days Requirements documentation07/25/2003 0 days Requirements classification07/20/2003

9. 14 th LectureCEN 4021: Software Engineering II 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. 14 th LectureCEN 4021: Software Engineering II 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. 14 th LectureCEN 4021: Software Engineering II Date Attribute-based Status DateExpected number of panels reviewed and approved Actual number of panels reviewed and approved Delta 07/05/200312 0 07/25/20031513-2 07/20/200320

12. 14 th LectureCEN 4021: Software Engineering II 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. 14 th LectureCEN 4021: Software Engineering II 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. 14 th LectureCEN 4021: Software Engineering II 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. 14 th LectureCEN 4021: Software Engineering II Function Attribute Completeness Monitoring FunctionExpected number of features Actual number of features Delta Function X139-4 Function Y770 Function Z9

16. 14 th LectureCEN 4021: Software Engineering II 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. 14 th LectureCEN 4021: Software Engineering II Software Process Activity-based Monitoring ActivitiesF1F2F3…Total Requirements definedYYY20 Function designedYYN12 Code implementedYNY15 Function testedYNN5

18. 14 th LectureCEN 4021: Software Engineering II 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. 14 th LectureCEN 4021: Software Engineering II Function Attribute-based Quality Monitoring Functional AreaSeverity level 1 problems found Delta Function X20 0 Function Y1210-2

20. 14 th LectureCEN 4021: Software Engineering II 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. 14 th LectureCEN 4021: Software Engineering II 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. 14 th LectureCEN 4021: Software Engineering II Defect removal activity-based quality monitoring ActivitiesF1F2F3…Total Requirements review(5,5)(6,6)(5,5)1 Design review(6,6)(7,6)(6,6)1 Functional testing(3,3)(2,2)(3,3)0 System testing(2,1)(1,1)(2,1)0

23. 14 th LectureCEN 4021: Software Engineering II 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. 14 th LectureCEN 4021: Software Engineering II 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. 14 th LectureCEN 4021: Software Engineering II 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. 14 th LectureCEN 4021: Software Engineering II Function Attribute-based Expense monitoring Functional AreaMonth 1Month 2…Accumulative Data ExpectedActualExpectedActualExpectedActual Function X43.55598.5 Function Y22.54567.5 Function Z7691016

27. 14 th LectureCEN 4021: Software Engineering II 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. 14 th LectureCEN 4021: Software Engineering II 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. 14 th LectureCEN 4021: Software Engineering II 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. 14 th LectureCEN 4021: Software Engineering II 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. 14 th LectureCEN 4021: Software Engineering II 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: 1.A means to collect the data, and 2.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. 14 th LectureCEN 4021: Software Engineering II 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. 14 th LectureCEN 4021: Software Engineering II 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. 14 th LectureCEN 4021: Software Engineering II 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. 14 th LectureCEN 4021: Software Engineering II 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: 1. Review of the project and product progress metrics: schedule, items completed, cost, defects discovered and corrected, and so on.

36. 14 th LectureCEN 4021: Software Engineering II Status Meetings 2. Review of personnel and resources: problems, rewards, and so on 3. Review of risk items: number, status, and so on 4. 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. 14 th LectureCEN 4021: Software Engineering II 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. 14 th LectureCEN 4021: Software Engineering II 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. 14 th LectureCEN 4021: Software Engineering II 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. 14 th LectureCEN 4021: Software Engineering II 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.