CEN 4021 Software Engineering II Monitoring POMA Instructor

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

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

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

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 15 th Lecture

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 – the stage of the project. – urgency of the activity. CEN 4021: Software Engineering II 15 th Lecture

Formal Data Gathering and Monitoring The data collection may also be based on: – project activities – project attribute. Both activity-based and attribute-based methods may be employed for measuring schedule goals. CEN 4021: Software Engineering II 15 th Lecture

Formal Data Gathering and Monitoring Activity-based monitoring: The activities may 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 15 th Lecture

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 15 th Lecture

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 15 th Lecture

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 15 th Lecture

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 15 th Lecture

Levels of Monitoring The major goals and measurements for software projects: – Schedule integrity – Completeness of function – Quality – Budget CEN 4021: Software Engineering II 15 th Lecture

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 15 th Lecture

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

Monitoring Quality 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 15 th Lecture

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 15 th Lecture

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 15 th Lecture

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 15 th Lecture

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 15 th Lecture

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 15 th Lecture

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 15 th Lecture

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 15 th Lecture

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 15 th Lecture

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 15 th Lecture

Levels of Monitoring Attribute-based monitoring cont – Some lump-sum expenses incurred at the beginning of the 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 15 th Lecture

Levels of Monitoring Activity-based monitoring cont – For each activity, the preparation for the measurement must be established by working with the financial organization. – Spmrs 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 15 th Lecture

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 15 th Lecture

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 15 th Lecture

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 15 th Lecture

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 spmr should be disciplined enough to log surprise items onto the list of high-risk items an immediately a separate session should be scheduled. – Key attendees should not be allowed to send substitutes. CEN 4021: Software Engineering II 15 th Lecture

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 15 th Lecture

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 15 th Lecture

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. Spmrs 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 15 th Lecture

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. Spmrs need to perform conscientious socializing. CEN 4021: Software Engineering II 15 th Lecture

Informal data gathering and monitoring Spmr 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 spmr’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 15 th Lecture

Informal data gathering and monitoring Physically remote environment – Many spmrs 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 spmr needs to make a special effort to meet them in person when they start the project. Establishing trust – The spmr must work to gain the trust of the members on the project team. CEN 4021: Software Engineering II 15 th Lecture

Informal data gathering and monitoring Establishing trust cont – The spmr must work to gain the trust of the members on the project team. – If a team member trust the spmr 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 15 th Lecture