CEN 4021 Software Engineering II Monitoring POMA Instructor

  • Slides: 40
Download presentation
CEN 4021 Software Engineering II Monitoring (POMA) Instructor: Masoud Sadjadi http: //www. cs. fiu.

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

Acknowledgements Dr. Onyeka Ezenwoye Dr. Peter Clarke CEN 4021: Software Engineering II 14 th

Acknowledgements Dr. Onyeka Ezenwoye Dr. Peter Clarke CEN 4021: Software Engineering II 14 th Lecture 2

Agenda Monitoring (POMA) – Monitoring Overview of Project Monitoring Data gathering and Monitoring CEN

Agenda Monitoring (POMA) – Monitoring Overview of Project Monitoring Data gathering and Monitoring CEN 4021: Software Engineering II 14 th Lecture

Project Monitoring The regular collection of project information that is considered relevant to the

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. CEN 4021: Software Engineering II 14 th Lecture

Formal Data Gathering and Monitoring Formal gathering of project information is usually performed at

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. CEN 4021: Software Engineering II 14 th Lecture

Formal Data Gathering and Monitoring For example, support manager may collect customer problem reporting

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. CEN 4021: Software Engineering II 14 th Lecture

Formal Data Gathering and Monitoring Activity-based monitoring: Consider the requirements gathering and analysis phase,

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. CEN 4021: Software Engineering II 14 th Lecture

Activity Completion Status Milestone activities Expected completion Actual Completion Delta Requirements interviews 07/05/2003 07/10/2003

Activity Completion Status Milestone activities Expected completion Actual Completion Delta Requirements interviews 07/05/2003 07/10/2003 +5 days Requirements documentation 07/25/2003 0 days Requirements classification 07/20/2003 CEN 4021: Software Engineering II 14 th Lecture

Formal Data Gathering and Monitoring Activity-based monitoring: The actual representation of the data collected,

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. CEN 4021: Software Engineering II 14 th Lecture

Formal Data Gathering and Monitoring Attribute-based monitoring: Consider the screen requirements prototyping task. It

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. CEN 4021: Software Engineering II 14 th Lecture

Date Attribute-based Status Date Expected number of panels reviewed and approved Actual number of

Date Attribute-based Status Date Expected number of panels reviewed and approved Actual number of panels reviewed and approved Delta 07/05/2003 12 12 0 07/25/2003 15 13 -2 07/20/2003 20 CEN 4021: Software Engineering II 14 th Lecture

Levels of Monitoring Generally activity-based data collection would apply better at a “macro” level

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. CEN 4021: Software Engineering II 14 th Lecture

Levels of Monitoring The major goals and measurements for software projects: – Schedule integrity

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. CEN 4021: Software Engineering II 14 th Lecture

Levels of Monitoring Attribute-based monitoring – The completeness of attributes may be viewed in

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. CEN 4021: Software Engineering II 14 th Lecture

Function Attribute Completeness Monitoring Function Expected number of features Actual number of features Delta

Function Attribute Completeness Monitoring Function Expected number of features Actual number of features Delta Function X 13 9 -4 Function Y 7 7 0 Function Z 9 CEN 4021: Software Engineering II 14 th Lecture

Levels of Monitoring Activity-based monitoring – At the macro level, manager may want to

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. CEN 4021: Software Engineering II 14 th Lecture

Software Process Activity-based Monitoring Activities F 1 F 2 F 3 Requirements defined Y

Software Process Activity-based Monitoring Activities F 1 F 2 F 3 Requirements defined Y Y Y 20 Function designed Y Y N 12 Code implemented Y N Y 15 Function tested Y N N 5 CEN 4021: Software Engineering II … Total 14 th Lecture

Levels of Monitoring Quality An attribute of a software product that describes how well

Levels of 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. CEN 4021: Software Engineering II 14 th Lecture

Function Attribute-based Quality Monitoring Functional Area Severity level 1 problems found Delta Function X

Function Attribute-based Quality Monitoring Functional Area Severity level 1 problems found Delta Function X 20 20 0 Function Y 12 10 -2 CEN 4021: Software Engineering II 14 th Lecture

Levels of Monitoring Attribute-based monitoring – Consider one possible goal of quality: to achieve

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. CEN 4021: Software Engineering II 14 th Lecture

Levels of Monitoring Activity-based monitoring – The results for activity-based monitoring looks a lot

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) CEN 4021: Software Engineering II 14 th Lecture

Defect removal activity-based quality monitoring Activities F 1 F 2 F 3 Requirements review

Defect removal activity-based quality monitoring Activities F 1 F 2 F 3 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 CEN 4021: Software Engineering II … Total 14 th Lecture

Levels of Monitoring The attribute-based and activity-based data collection mechanisms are very similar for

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. CEN 4021: Software Engineering II 14 th Lecture

Levels of Monitoring the Budget An attribute of a software project that describes the

Levels of 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 CEN 4021: Software Engineering II 14 th Lecture

Levels of Monitoring Attribute-based monitoring – Budget related data may be collected with the

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. CEN 4021: Software Engineering II 14 th Lecture

Function Attribute-based Expense monitoring Functional Area Month 1 Month 2 … Accumulative Data Expected

Function Attribute-based Expense monitoring Functional Area Month 1 Month 2 … Accumulative Data Expected Actual Function X 4 3. 5 5 5 9 8. 5 Function Y 2 2. 5 4 5 6 7. 5 Function Z 7 6 9 10 16 16 CEN 4021: Software Engineering II 14 th Lecture

Levels of Monitoring Attribute-based monitoring – An expense entry for each software function includes

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. CEN 4021: Software Engineering II 14 th Lecture

Levels of Monitoring Attribute-based monitoring cont – Some lump-sum expenses incurred at the beginning

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. CEN 4021: Software Engineering II 14 th Lecture

Levels of Monitoring Activity-based monitoring cont – For each activity, the preparation for the

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. CEN 4021: Software Engineering II 14 th Lecture

Data Collection Schedule Formal collection of data for the purpose of project monitoring should

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. CEN 4021: Software Engineering II 14 th Lecture

Status Meetings Formally collected data should be presented by the project team members to

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. CEN 4021: Software Engineering II 14 th Lecture

Status Meetings Data collection automation/tools – Information from various stages of the s/w development

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. CEN 4021: Software Engineering II 14 th Lecture

Status Meetings Formal project status meeting cont: – Key personnel (managers and project team

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. CEN 4021: Software Engineering II 14 th Lecture

Status Meetings Formal project status meeting cont: – Meetings are usually well attended at

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. CEN 4021: Software Engineering II 14 th Lecture

Status Meetings Formal project status meeting cont: – Each time slot should include a

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. CEN 4021: Software Engineering II 14 th Lecture

Status Meetings – 2. Review of personnel and resources: problems, rewards, and so on

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. CEN 4021: Software Engineering II 14 th Lecture

Informal data gathering and monitoring S/w projects depend heavily on the performance of people.

Informal data gathering and monitoring S/w projects depend heavily on the performance of people. Human performance is based on some hard-toget 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 managers need to perform conscientious socializing. CEN 4021: Software Engineering II 14 th Lecture

Informal data gathering and monitoring project manager should perform the following to keep the

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. CEN 4021: Software Engineering II 14 th Lecture

Informal data gathering and monitoring Physically remote environment – Many project managers have virtual

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. CEN 4021: Software Engineering II 14 th Lecture

Informal data gathering and monitoring Establishing trust cont – The project manager must work

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. CEN 4021: Software Engineering II 14 th Lecture