Printshop Workflow Automation System

P.W.A.S

P.W.A.S. Printshop Workflow Automation System

Operational Plan (Adjustment)

Project Time Frame: March 2010 – Jun 2010 Barbara Gonzalez. PID: 2900267 CEN 4021 Software Engineering II Professor S. Masoud Sadjadi Florida International University April 2010 P.W.A.S

Preface

This document includes only the Adjustment Part for the Project Plan. The Adjustments section was numbered as Section 7 with the purpose of maintaining consistency with the original Project Plan. In addition, this document also includes the Risk Analysis Section (numbered as Section 5 for the same previous purpose) given its relevancy to the Adjustment process. Moreover, section 6.2.8 Functional Attribute-Based Quality Monitoring is also included given its relevancy to the adjustments described in this document. Finally a segment of the Appendix section (numbered as Section 8) is also included in order to display relevant information in a visual way as well and mostly in order to reflect the changes to the Project Schedule (added Adjustment Meetings). P.W.A.S

Table of Contents

5. Risk Analysis. 1 5.2. Major sources of Risk 1 5.3. Risk Mitigation 1 5.4. Risk Prioritization by Recovery Cost 3 5.5. Risk Prioritization by Risk Value 4 6. Monitoring 5 6.2 Analyzing Project Information 5 6.2.8 Functional Attribute-Based Quality Monitoring 5 7. Adjustments 6 7.1 Planned Adjustments 6 7.1.1 Process and Methodologies 6 7.1.2 Adjustments Made 7 7.2 Unplanned Adjustments 7 7.2.1 Process and Methodologies 7 7.2.2 Adjustments Made 8 8. Appendix 10 8.1. Sequence Diagram with estimated times. 10 8.2. Schedule Allocation. 11 8.3. Monitoring 12 8.3.1. Functional representation of found errors. 12 P.W.A.S

5. Risk Analysis

5.1 Major sources of Risk:

 R.1 Overly optimistic assumptions about the availability of some technology like AJAX or LINQ to SQL  R.2 Difficulties faced because of the chosen technology. Meaning problems related to developing technologies such as AJAX and LINQ to SQL mainly.  R.3 Miscalculation of the robustness (e.g., extensibility) or constraints of software design.  R.4 Misunderstanding of customer requirements.  R.5 Uncontrolled continuous changes of customer requirements.  R.6 Unrealistic promises to customers made by overzealous salespeople or company executives.  R.7 Incompetence of key project personnel like the Designer or the Test Analyst.  R.8 Miscalculation of teamwork and group effectiveness.  R.9 Unrealistic expectations about the availability or productivity of special skilled human resources.  R.10 Loss of human resources.  R.11 Underestimation of known tasks.  R.12 Underestimation of the impact of known tasks  R.13 Underestimation of the dependencies between tasks.

5.2 Risk Mitigation

of 19 P.W.A.S

 R.1 Overly optimistic assumptions about the availability of some technology like AJAX or LINQ to SQL o Alternative 1: Evaluate alternative technologies.  R.2 Difficulties faced because of the chosen technology. Meaning problems related to developing technologies such as AJAX and LINQ to SQL mainly. o Alternative 1: Buy support time from Microsoft. o Alternative 2: Evaluate alternative technologies.  R.3 Miscalculation of the robustness (e.g., extensibility) or constraints of software design. o Alternative 1: Time for Design review will be scheduled after the design document is complete. o Alternative 2: Time for Design change and impact management will be scheduled after the design document is complete.  R.4 Misunderstanding of customer requirements. o Alternative 1: Some key representatives of the customer side will be encouraged to actively participate of every stage of the process. So issues may be clarified as soon as they arise.  R.5 Uncontrolled continuous changes of customer requirements. o Alternative 1: Some key representatives of the customer side will be encouraged to actively participate of every stage of the process. So they can be aware of the implications of every requested change. o Alternative 2: Every requested change will be assessed, measured, tracked. Only those who passed the evaluation process will be implemented.  R.6 Unrealistic promises to customers made by overzealous salespeople or company executives. o Alternative 1: Some key representatives of the customer side will be encouraged to actively participate of every stage of the process. So they can be aware of the implications of changes.  R.7 Incompetence of key project personnel like the Designer or Test Analyst. o Alternative 1: Keep resumes of people with the necessary skills for these positions as a backup option.

of 19 P.W.A.S

 R.8 Miscalculation of teamwork and group effectiveness. o Alternative 1: Deep analysis of the team performance in previous projects. o Alternative 2: Provide incentives for people to cooperate.  R.9 Unrealistic expectations about the availability or productivity of special skilled human resources. o Alternative 1: Keep resumes of people with the necessary skills for these positions as a backup option.  R.10 Loss of human resources. o Alternative 1: Provide extra incentives to persuade the current employee to stay. o Alternative 2: Hire an extra person with the needed skill as a backup helper.  R.11 Underestimation of known tasks. o Alternative 1: Renegotiation of the delivery date. o Alternative 2: Schedule overtime work. o Alternative 3: Hire additional personnel.  R.12 Underestimation of the impact of known tasks o Alternative 1: Schedule regular status meetings to stay aware of the project status.  R.13 Underestimation of the dependencies between tasks. o Alternative 1: Schedule regular status meetings to stay aware of the project status.

5.3 Risk Prioritization by Recovery Cost

Risk Item Recovery Cost Risk Priority R.1 3 Medium R.2 2 Low R.3 2 Low R.4 4 High R.5 5 High R.6 4 High R.7 3 Medium R.8 2 Low R.9 2 Low

of 19 P.W.A.S

R.10 3 Medium R.11 3 Medium R.12 4 High R.13 5 High

5.4 Risk Prioritization by Risk Value

Risk Item Probability of Occurrence Recovery Cost Risk Value R.1 0.2 $2,000 400 R.2 0.5 $1,000 500 R.3 0.3 $2,000 600 R.4 0.2 $8,000 1,600 R.5 0.05 $15,000 750 R.6 0.05 $15,000 750 R.7 0.1 $3,000 300 R.8 0.2 $2,000 400 R.9 0.2 $6,000 1,200 R.10 0.1 $10,000 1,000 R.11 0.3 $4,000 1,200 R.12 0.3 $4,000 1,200 R.13 0.3 $6,000 1,800

of 19 P.W.A.S

6. Monitoring

6.2 Analyzing Project Information

6.2.8 Functional Attribute-Based Quality Monitoring This table will be maintained by the project manager with the purpose of having a general idea in regards to the software’s quality in terms of high-severity, medium-severity, and low-severity errors.

Functional High-severity High-severity Medium- Medium- High- Medium- Area problems problems severity severity severity severity found fixed. problems found problems fixed delta Delta F1 15 5 25 20 -10 -5 F2 30 21 36 34 -9 -2 F3 34 25 35 11 -9 -24 F4 29 27 22 18 -2 -4 F5 10 10 10 8 0 -2

Conclusion: Taking into account the information in the above table, we could say the team is reporting too many high-level and medium-level errors. The historical average for similar projects for Medium-severity errors is: 25 errors with a standard deviation of 5 and for High- severity errors is: 20 errors with a standard deviation of 4. This data shows numbers much higher compared to those historical results which clearly means that we have a problem. Either the team members are not clear in the definitions for each problem category, the developers are not been careful enough during the implementation of the functionalities, or the tests performed in order to evaluate the functionalities are not the correct ones.

of 19 P.W.A.S

7. Adjustments

7.1 Planned Adjustment

7.1.1 Process and Methodologies: In order to adequately plan for adjustments, we will be having an Adjustment Meeting at the end of every major activity, the review will be centered in Functionality, Resources, and Schedule. These major activities are marked in our project with milestones. Therefore, we will be having an Adjustment Meeting the day after each Milestone is due.

The participants for these Adjustment Meetings will include:

Project Manager: Barbara Gonzalez Designer: Javier Mesa Developer: Dulcardo Arteaga Test Analyst: Rolando Vicaria Documenter: Naveen Gouda

The general Agenda for the Adjustment Meetings will include:

• The status of unresolved items • The status of risk items • New, but regular, tracking data collected for this period by attribute (such as schedule, functionality, quality, resources, and cost) • General inputs from the specialized areas represented by the participants • A short discussion and scheduling of any off-line meetings • The generation of status and follow-up open items

Note: The planned adjustment for our project also includes the Risk Mitigation. Risk Mitigation can be found in section 5.2 of the original the Project Plan and this document.

of 19 P.W.A.S

7.1.2 Adjustments Made

Up to the current point in the project, the planned adjustments made include:

 Adjustments related to risk R.2 Difficulties faced because of the chosen technology. Meaning problems related to developing technologies such as AJAX and LINQ to SQL mainly. The chosen alternative was Alternative 1: Buy support time from Microsoft. Luckily, with only 3 sessions, all the problems faced have been solved and our developers have been able to keep taking advantages of these technologies.

Summarized Budget Activity Estimated budget Human resources $93,136 Software Resources $5,000 Hardware Resources $5,580 Recovery Expenses $15,000 - $1,500 = $13,500 Total $118,716 Note: After this adjustment the part of the budget available for Recovery Expenses was reduced to $13,500.

7.2 Unplanned Adjustments 7.2.1 Process and Methodologies

For unplanned issues that may arise, a process and a methodology for Adjustment also need to be in place.

A general approach to deal with these unplanned problems will include:

1. Clearly state the problem. 2. Communicate the problem while working on the potential solutions to it.

of 19 P.W.A.S

3. Seek out the root cause of the problem and any relevant solutions. 4. Gain the necessary agreement for the chosen solution (The proposed solution must be worked out with all the project’s stakeholders.) 5. Act on the solution. 5.1 Identify the changes 5.2 Asses the changes 5.3 Measure the changes 5.4 Track the changes 6. Communicate on the action. 7. Report on the status of the problem’s resolution.

7.2.2 Adjustments Made

Up to the current point in the project, the unplanned adjustments made include:

 According to the information gathered and analyzed during the monitoring, we were able to identify that the team is reporting too many high-level and medium-level errors. The historical average for similar projects for Medium-severity errors is: 25 errors with a standard deviation of 5 and for High-severity errors is: 20 errors with a standard deviation of 4. The gathered data shows numbers much higher compared to those historical results which clearly means that we have a problem.

The proposed solution to this issue was to implement some of the elements of the Extreme Programming methodology. o Developers will work in pairs for two weeks. o Extensive code review and unit testing will be done.

The first week was intended for the developers to get use to this new methodology and get comfortable working together. The second week was intended to get representative results about the problem.

of 19 P.W.A.S

Cost: o Two weekends one in April and the other one in May were allocated as work days for developers and the Database Administrator. o The previous 32 hours of overtime will be paid at 150%.

Summarized Budget Activity Estimated budget Human resources $93,136 Software Resources $5,000 Hardware Resources $5,580 Recovery Expenses $15,000 - $1,500 = $13,500 – 5,496 = $ 8,004 Total $118,716  Note: After this adjustment the part of the budget available for Recovery Expenses was reduced to $8,004.

Purpose: During this two weeks experimental period the developers will be able to evaluate their peer’s development strategies and therefore auto-evaluate themselves. In addition they can provide and obtain feedback and as a consequence the code in development will be more extensively reviewed. Hopefully, this core reviewing and developing strategies will keep being applied by the developers when the experimental period is over.

of 19 P.W.A.S

8. Appendix

8.1 Sequence Diagram with estimated times.

of 19 P.W.A.S

Legend:

Dependency

Critical Path

of 19 P.W.A.S

8.2 Schedule Allocation

of 19 P.W.A.S

8.3 Monitoring

of 15 P.W.A.S

8.3.1 Functional representation of found errors.

30 Historical Average 25 Medium-severity Errors found 20 Historical Average High-severity High-severity 15 Medium-severity

0 F1 F2 F3 F4 F5 Functional Area

Conclusion: Taking into account the information in the above table, we could say the team is reporting too many high-level and medium-level errors. The historical average for similar projects for Medium-severity errors is: 25 errors with a standard deviation of 5 and for High-severity errors is: 20 errors with a standard deviation of 4. This data shows numbers much higher compared to those historical results which clearly means that we have a problem. Either the team members are not clear in the definitions for each problem category, the developers are not been careful enough during the implementation of the functionalities, or the tests performed in order to evaluate the functionalities are not the correct ones.