Software process

Começar. É Gratuito
ou inscrever-se com seu endereço de e-mail
Software process por Mind Map: Software process

1. CAR (casual analysis resolution ) process

1.1. 2 .correct action

1.1.1. identify defects problems non fulfillment of define processes non conformities customer complaints

1.1.2. analyze

1.2. 1. prevent action

1.2.1. make Development Plan

1.2.2. Review DP plan

1.2.3. CAR meeting

1.3. 2.1 Techniques

1.3.1. Pareto Chart: (20% sources that cause 80% problem),

1.3.2. Brainstorming All members must speak out The success of meeting depends on the follow up.

1.3.3. Cause-Effect diagram Fish-bone

1.3.4. 5 –WHY

2. Project Communication Management

2.1. evaluate the level of PM

2.1.1. ask stakeholders what they need from/to

2.1.2. team comminiicate Task assignment & tracking Issue escalation & resolving Evaluation, Information, Motivation,

2.2. important skill of GREAT Project Manager

2.2.1. prevents many potential problems

2.2.2. major key success factor

2.3. 90% time of Project Manager

2.3.1. communicate via phone, emails, meetings GREAT Meeting Goal Oriented Right People Expectations Clarified Agenda in Advance Time Sensitivity Better Emails Avoid the use of slang words NOT to use abbreviations Steer away from the use of symbols Brackets are used to play down words or phrases Dashes are generally used for emphasis Cliches should be avoided Cliches should be avoided

2.3.2. Create Project Communication Plan

2.3.3. Performance Reporting Progress Reports Status Reports Forecast Report Why Report Inform sponsor and users Inform sponsor and users Inform team members Communicate changes, issues, risks Maintain interest and involvement Share the good news, as well as bad

2.4. KEY

2.4.1. Who are you speaking to What are their interests, presuppositions and values? What do they share in common with others? How are they unique?

2.4.2. What do you wish to communicate?

2.4.3. How can you best convey your message?

2.4.4. When Time Sensitivity It’s better to be silent than sing a bad tune

2.4.5. Where What is the physical context

2.4.6. Why Why they should listen to you What disposes them to listen? the value or worth or interest of what you are going to say.

2.5. Case studies

2.5.1. Use wrong media to discuss with customer

2.5.2. Forgot to take meeting minutes.

2.5.3. Forgot distribute minutes to customer/end-user to confirm and keep evidence.

3. HR Management

3.1. Human Resource Planning

3.1.1. determines project roles, responsibilities and reporting relationships PM’s Responsibilities: Overall responsibility for the project management process Manage expectation of project organization Develops all deliverables Keeping track of schedules and time management Executes quality reviews (formal and management) Update project data/records following procedures Administers change requests and issues Keep Project Sponsor and team informed of progress, issues and concerns Team’s Responsibilities Contribute to the project management plan (Define and estimate time of task). And accomplish work defined in the project scope statement (WO). Attend project team meetings Process improvement Comply with quality and communications plans Define the products of project Identify and analyze constraints, assumptions, risks Define detailed requirements Create WBS Identify dependencies, provide time and cost estimates Log data: timesheet, defects to Fsoft tools Produce project performance reports Measure project performance Close out phases of the project

3.1.2. Main Outputs Roles and Responsibilities (Responsibilities Assignment Matrix) Project Organization Charts Staffing Management Plan Describe when and how human resource requirements will be added and released from the project. Resource Histogram

3.2. Human Resource Monitoring

3.2.1. Activities Manage Project Resources Main Activities: Main outputs: Assess and Refine Project Organization Structure Assess and Refine Team Skill Main Activities Main outputs: Ensure team skills meet competencies

3.2.2. outputs Project Organization Teams: Development team, Test team, Comtor,… Project Organization Structure Team members with effort allocation Effort budget for the project

3.3. Develop project team

3.3.1. “improves the competencies and interactions of team members to enhance project performance”

3.3.2. Improves skills of team members

3.3.3. Improves feeling of trust and cohesiveness

3.3.4. It is CRITICAL to the success of project

3.3.5. Should be conducted early and is an ongoing activity

3.3.6. KEY Team building Milestone parties Holiday and birthday celebration Outside of work trips Creating the WBS Planning the project by getting everyone involved. Training: in order to perform project or enhance team member performance. Ground rules (establish clear expectations) Co-location (war room) Recognition and rewards (of desirable behavior) Team performance Assessment Public the rewards

3.4. Manage project team

3.4.1. PM should Observe Use Issue log Keep in touch Actively look for and help resolve conflicts that the team cannot resolve.

3.4.2. Leadership Directing: Tell others what to do Facilitating: Coordinating the input of others Coaching: Instructing others Supporting: Providing assistance along the way Autocratic: Making decisions without input. Consultative: Inviting ideas from others: Consensus: group problem solving.

3.5. Conflict and Resolve Techniques

3.5.1. Conflict from a disagreement between people on substantive Goals Rewards Procedures Resources Policies Job Assignments emotional issues. Feelings of anger, distrust, dislike, fear and resentment Personality clashes

3.5.2. Resolve 1. Schedules 2. Project priorities 3. Resources 4. Technical opinions 5. Administrative procedures 6. Cost 7. Personality

4. Project Planning

4.1. Project Opening

4.1.1. Initial Project Plan Initialing process group

4.2. Project Planning

4.2.1. Overview Planning Process Group

4.2.2. Steps of project planning

4.3. Project monitoring

4.3.1. Monitoring process group Requirement Management Activities: Output: Human Resource Management Activities: Output: Risk Management Activities: Output: Cost Management Activities: Output: Payment Management Activities: Manage Project Payment Output: Process Management Activities: Output: Stakeholder Management Activities: Manage relevant stakeholders Output: Schedule Management Check and update status in project schedule Evaluate deviation and analyze, find, understand cause Output : updated project schedule Task Management Output Activities Quality Management Output: Activities: Payment Management Billing schedule must be conformed to payment deadline: put into project plan. Payment Criteria should be addressed clearly Being fully paid is a project’s objectives All payment criteria are achieved before payment deadline Once all criteria is achieved, the acceptance letter is prepared and get customer approved. Actual effort is calculated by PM, if over estimated, should negotiate for extra value.

4.4. Project closing

4.4.1. Closing Process Group Activities: Initiate Project Termination Obtain Customer Acceptance Issue Final Invoice Finalize Project Information Analyze Project Performance Capture Practices/Lessons Learned Complete Post-mortem Report Conduct Post-Mortem Meeting Distribute Post-Mortem Report Evaluate Team Performance Hand-Over Project Assets Complete Internal Acceptance Note Output: Post-Mortem Report; Post-Mortem Meeting Minutes Project Final Status Report Completed Project Acceptance Letter. CSS; Invoices Project Data Written feedback to Project Team member Project Asset is archived in Wrap-up Baseline and handed-over to SC QA. Accounting Document confirming that no customer-owned IP has been retained

4.5. Case studies

4.5.1. Possible solutions to common issues Training people if they lacks skills Review the priority of tasks and do not accept new tasks if behind schedule Regularly monitoring cost to avoid over-run effort Strictly follow Requirement Change Management workflow since scope keeps changing, many requirements arise. Review Payment schedule & Payment criteria in the Contract/External Work Order Prepare Acceptance Letter and send to customer to obtain customer approval when payment criteria are achieved and payment schedule is reached Issue Invoice and rectify any problem encountered, work with PMs, AF and customer to resolve the problems. Control payment progress until the invoices are fully paid.

5. Quantitative Management

5.1. Purpose

5.1.1. Quantitatively manage the project’s defined process to achieve the project’s establish quality and process performance objectives

5.2. Software Metrics

5.2.1. What It is a measure of quantity of something. Usually a number For example: the water level of Red River

5.2.2. Why Quicker transfer/communication Automation/alerts Filtering (who needs to know what) Consolidate & predict the future (statistical analysis, PCB)

5.2.3. Requirement Metrics: Requirement Completeness (%): Measures percentage of requirement completed against the committed and predict the amount of remain work = ∑(Requirement Size x Requirement Completed Rate)*100/Total Committed Requirement Size Requirement Stability (%): Measures stability of requirements, frequency of requirements changed by customer = (Total size of change requests / Total size of requirements)*100

5.2.4. Quality Metrics Defect Rate (wdef/size): Measures quality of overall project's products. = Total No of weighted Defects of a product/Product Size Product Size could be = Effort usage/KLOC/UCP/FP/Module Defect Removal Efficiency (%):Provides the efficiency of review / test processes = (Total No of Project Defect - No of defects detected by Role = Customer)/ Total project defects * 100% Leakage (wdef/size): Measure quality of the product and service after delivery for acceptance test. = No of Wdef Defects detected after delivery for acceptance test of a product/Product size Customer Satisfaction (Point): Measures the satisfaction of customer requirements

5.2.5. Cost Metrics: Effort Efficiency (%): Measure efficiency of project effort usage = (Billable Effort/ Calendar Effort)*100 (1MM=21Pds) Effort Effectiveness (%): Provides tracking of budgeted effort against actual effort and predict future effort = (Last Committed Effort Usage/Actual Effort Usage)*100 Quality Cost (%): Provides the cost that project pays for quality and efficiency of quality activities in project = Effort spent for quality activities x 100/ total project effort Correction Cost (%): Indicates cost of correcting a defective product and the associated rework/damage costs = Effort spent for fixing error x 100/ total project effort Project Management (%)= Effort spent for project management x 100/ total project effort

5.2.6. Productivity Metrics: Productivity (Size/pd) : Provides the measurement about general productivity in project = Product size/Total effort Coding Productivity= Product size / Coding Effort Size: About LOC , we can use Blue Step Counter and Kazoe-Ciao tool to count actual LOC.

5.2.7. Schedule Metrics: Timeliness (%): Measures the ability to satisfy customer in timeliness. = (No of deliverable delivered on time/ Total # of deliverables delivered)*100 Schedule Deviation (%): Provides information on project performance with respect to its schedule commitment = ((Actual duration- Last committed duration)/ Last committed duration)*100

5.2.8. Process Compliance: Process Compliance (%): Measure the compliance of project activities as with the defined rule/standard/process/regulation = SUMPRODUCT(checked items, assessment results)/SUM(checked items). Note: only include checked items with assessment results = 0, 50, 100.

6. Risk Management

6.1. Risk Management Basics

6.1.1. Risk: any uncertain event / condition that might affect your project.

6.1.2. Risk details: source, condition, consequence, probability, impact, priority.

6.1.3. Where to look for risks? Dependencies: HR, tool, equipment, etc. Assumptions: may not actually be true. Project characteristics: objectives, requirement, design, implementation, testability, etc. Activities on the critical path Team spirit and attitude Outside project: organization, policies, rules, standards, …

6.1.4. risk process risk management process

6.2. Risk Planning

6.2.1. Identify project risks: Perform an initial risk assessment Use Template Risk Management Sheet Document defined risks

6.2.2. Analyze each risk: Define the cause and consequence of each risk. Estimate the probability of each risk occurring and the impact of each risk if it does occur (see Guideline for how). Calculate the exposure value for each risk (Risk Exposure = Probability x Impact). exposure value of a risk is the expected value of the loss for the risk Prioritize risks basing on their exposure value Define Risk Exposure threshold to determine which risks (the top few) need mitigation and contingency plans.

6.2.3. Do Create risk mitigation and/or contingency plans for each risk need to be handled. Update Project WBS and Project Schedule accordingly. Define risk triggers Assign owners who will automatically begin executing the risk contingency plan if risk is triggered.

6.3. Risk Monitoring

6.3.1. Activities Recognize new or suspected risks in project Record in Project Risk List, and analyze the risks Define action for risk mitigation and contingency, as appropriate Assign resource to implement the actions and ensure they have sufficient time and resource to complete them Monitor trigger for any contingency plans Initiate contingency plan if triggers are met. Report status on risk status and associated response actions to relevant people

6.3.2. Work products Mitigation and contingency plans for risks Updated Project Risk List with identified risks, risk owners, mitigation plans, and contingency plans Risk information for status reports

6.4. Case Study

6.5. Common Risks

6.5.1. Some apps can not finished because Device not available

6.5.2. Many new members, few time for training, could not keep the productivity

6.5.3. Customer could not keep the plan of UAT

6.5.4. Running Visual studio for load testing has some error in the code Forum’s DLL sent from customer.

6.5.5. Team members have not much experience with IT Spec of PMC process so take more time to create IT Spec (test policy, test viewpoint, function list) [Impact] Effect to schedule of IT (do not keep release date of these products)

6.5.6. There are some change requests from customer so the final release is delayed

6.5.7. The initial version of STS is still the draft version, CRs are expected.

6.5.8. Customer evaluates test environment setting for Phone is difficult -> consider risk test environment

6.5.9. Team spirit is down and many resources are out of project. Inexperience team, lack of resource, not stable.

6.5.10. New PM, no experience in project management

7. Scope Management

7.1. Project scope: is the work to be done to deliver a product, service with specified features and functions.

7.2. Project scope management: the processes to ensure that all required work of project complete successfully.

7.3. Project scope management processes: processes to define/document, manage, verify and control what is or is not included in a project

7.3.1. diagram Collect requirement: define and document stakeholders’ needs to meet the project objectives. Project charter Stakeholder register Indentifying external interfaces Analyzing high level requirements Studying and Questionnaires Meeting with customer for clarifying Brainstorming and lateral thinking to decide technical solution Prototypes Define scope: develop detailed description of project by breaking the major project deliverables into smaller and more manageable components (Work Breakdown Structure/WBS). Project charter Requirements documentation Organization process assets Decomposition in WBS Others Work breakdown structure (WBS) Verify scope: formalize acceptance of completed project deliverables. Input Technique Output Control scope: monitor status of project scope and manage the changes to scope baseline. Input Technique Output

8. Project Estimation

8.1. WHY

8.1.1. One of the most challenging and important activities in project management

8.1.2. 70-80% of failed projects are due to bad estimation.

8.1.3. Under-estimating a project leads to staff burnout, low quality, missing deadline.

8.1.4. Over-estimating a project leads to resource usage inefficiency, lost opportunities.

8.2. Estimate process

8.2.1. Estimate Size A predominant factor in determining how much effort is needed used for initial estimation Functional requirements must be defined before using methods Work Breakdown Structure (WBS) - popular estimation method Line of Code (LOC) - done by experienced people and historical data, no guideline Function Points (FPs) Use-case Points Verify estimation result using 2 or more than 2 methods By Analogy By Analysis PM develop own method if standard method not suitable Break product down into smaller parts (features, use cases, user stories, etc) FP, UCP are suitable

8.2.2. Estimate Effort Top-down approach: Use size estimate with historical data of productivity in PCB to derive total estimated project effort Convert size to effort by regression analysis of the past data Determine effort of various by percentage of the total effort Bottom-up approach: easier to prepare in some situations instead of explicit size estimate Risk: some important activities may be omitted Estimate first for each part of the project then estimate all project, using activity-based or function-based WBS Advantage: requires a list of project tasks

8.2.3. Estimate Schedule Determine the project schedule from the effort estimate. Various schedules are possible depending on the number of people needed for the project Remember that effort and months are not fully interchangeable in a software project. Refer to Holiday calendar Estimate the project duration in calendar months. Determine starting points, duration and ending point of the project. Tools/Techniques for scheduling: Network Diagram, Grant Chart, Critical Path Investigate these techniques in section Time Management

8.2.4. Estimate Human Resource Determine the skills required to accomplish the activities Using skill sheet Check for the availability of team members for skills Manager need to commit availability Functional manager assesses skill set and required effort Estimate overall cost according to the cost that manager of these people inform

8.2.5. Estimate Infrastructure Resource Some methods: historical experience, simulations, prototyping, and analysis Includes: Computer memory capacity, Computer processor use, Communications channel capacity Steps for estimating resources PM identifies resources for the project PM estimates resources in consistence with the estimates of: Steps for managing resources Estimates for the project's infrastructure resources Planned computer resources, the system requirements allocated to software Available computer resources are allocated to the software components Available capacity for the infrastructure resources provides for a specified reserve capacity when the initial estimates are made. Estimating new development projects: use UCP, FP, WBS, LOC.

8.2.6. Verify Estimation Verify quality of the estimation and to get it approved Confirm the software architecture and functional WBS Verify the methods used for deriving the size, schedule and cost estimates Ensure that the assumptions and input data used to develop the estimates are correct Ensure that the estimate is reasonable and accurate given the input data Formally confirm and record the official estimates for the project.

8.2.7. Track and Record Estimates Tracked overtime Re-estimate weekly, at milestones or when the level of uncertainty or project scope is changed. All estimation data, both planned and actual, need to be recorded in the Software Process Database. Historical data is used for estimating for future projects

8.3. Different Kind of Projects

8.3.1. Estimating maintenance & enhancement projects: may have to reverse engineering, rework the architecture, study the existing code, perform regression and integration testing for the whole system etc.

8.3.2. Estimating “new domain” projects: always high risks and under-estimated. make the risks very clear to stakeholders, avoid making commitment to fixed deadlines, suggest POC or prototype, re-estimate when familiar with the domain.

8.3.3. Estimating agile projects: estimate relative size of the backlog items in Story Points Calculate & use team velocity to estimate effort and schedule for each iteration.

8.4. Estimating Tips

8.4.1. If we lengthen the schedule, we can generally reduce the overall cost and use fewer people.

8.4.2. Allow enough time to do a proper project estimate.

8.4.3. Use historical data from our own similar projects in the past where possible.

8.4.4. Use Developer-based estimates.

8.4.5. Use At least one software estimation tool.

8.4.6. Use several different people to estimates and use several estimation techniques to compare the results.

8.4.7. Re-estimate the project several times throughout its life cycle.

8.4.8. Spend some effort on improving your estimation skills by comparing actual to estimate when project is completed.

9. Configuration Management

9.1. CM Facts

9.1.1. Use not latest revision

9.1.2. not comment when commit svn, overwrite others' file

9.1.3. wrong environment

9.2. CM Activities

9.2.1. Configuration Identification work products Requirement – URS, SRS Design – ADD, DD Coding – Software module, Software package Test – TP, TC, TR plan documents CM plan

9.2.2. Configuration Control Purpose Ensure all the changes to the work product are in controlled How Need tools to control the changes by following the defined process Change request form are introduced and must be filled before All the changes must be reviewed Manage version Permission control Change Request Form What Why When How Release management Category of CI to release Build Release checklist Build Release workflow

9.2.3. Configuration Status CM Report Purposes Types Contents

9.2.4. Configuration Audit Purposes Track status of changes to CIs in Change Control Report Ensure that CM plan is implemented correctly Provide CM accounting status How to audit? Process Compliance Verification Internal Audit (CM) Output Process Compliance Verification checklist Internal Audit checklist who QA configuration manager

10. Time Management

10.1. Definition

10.1.1. process of organizing and planning how to divide your time between specific activities. Good time management enables you to work smarter – not harder

10.1.2. Failing to manage your time Missed deadlines. Inefficient work flow. Poor work quality. A poor professional reputation and a stalled career. Higher stress levels.

10.1.3. What Greater productivity and efficiency. A better professional reputation. Less stress. Increased opportunities for advancement. Greater opportunities to achieve important life and career goals.

10.2. How

10.2.1. Goal Setting How SMART Why long-term vision and short-term motivation measure and take pride in the achievement see forward progress raise your self-confidence Key Points Deciding what you want to achieve in your life. Separating what's important from what's irrelevant, or a distraction. Motivating yourself. Building your self-confidence, based on successful achievement of goals. Achieving Goals If you achieved the goal too easily, make your next goal harder. If the goal took a dispiriting length of time to achieve, make the next goal a little easier. If you learned something that would lead you to change other goals, do so. If you noticed a deficit in your skills despite achieving the goal, decide whether to set goals to fix this.

10.2.2. Prioritization What what needs to be done is especially important how To-Do List

10.2.3. Managing Interruptions what phone calls, information requests, questions from employees, and a whole host of events that crop up unexpectedly How Keep An Interrupters Log Analyze and Conquer Interruptions Put Your Phone to Work for You (Not Against You) Catch Your Breath Learn to Say "No" "Available" and "Unavailable" Time

10.2.4. Procrastination What In a nutshell, you procrastinate when you put off things that you should be focusing on right now procrastination occurs when there’s “a temporal gap between intended behavior and enacted behavior. How Recognize That You're Procrastinating Work Out WHY You're Procrastinating Adopt Anti-Procrastination Strategies Key Points

10.2.5. Scheduling Importance Understand what you can realistically achieve with your time. Make sure you have enough time for essential tasks. Add contingency time for "the unexpected." Avoid taking on more than you can handle. Work steadily toward your personal and career goals. Have enough time for family and friends, exercise and hobbies. Achieve a good work-life balance. How Identify Available Time Schedule Essential Actions Schedule High-Priority Activities Schedule Contingency Time Schedule Discretionary Time Analyze Your Activities Key Points

11. Scrum

11.1. 3 pillars

11.1.1. 1. Transparency

11.1.2. 2. Inspection

11.1.3. 3. Adaption

11.2. ROLEs

11.2.1. 1. Product owner 1. Business Value 2. Prioritize the product backlog Product Backlog 3. Final arbiter of the requirements questions 4. Focused more on what rather than how? 5. Vision and boundaries.

11.2.2. 2. Scrum Development Team 1. Cross functional and self Organizing. 2. Attempt to make a "Potentially Shippable Product Increment" Every sprint. 3. Collaborates 4. Have autonomy regarding how to reach commitment. 5. Collocation especially for first few sprints 6. 7+_2 7. Has a leadership role.

11.2.3. 3. Scrum Master 1. No management authority. 2. Moves impediments out of the team. 3. Keeps the team away from other distractions. 4. Doesn't have a Project Manager role. 5. Acts as a facilitator. 6. Gets the team out of the way for natural team self organization. 7. Helps people to train on scrum 8. Promotes improved engineering practices. 9. Enforces time boxes, provides visibility. Time Boxing: Having a limit on time availability for meetings etc. 10. Captures imperical data to adjust forecasts. 11. Makes sure scrum artifacts are available. 12. No decision making authority during the sprints. 13. Increase rigor in the definition of done.

11.3. Meetings

11.3.1. 1. Sprint planning meeting PO and the Scrum Dev team will agree to the Sprint goals and negotiate which items from the product backlog will be committed to the sprint backlog.

11.3.2. 2. Daily Scrum What did I do Yesterday? What will I do today? What impedes me?

11.3.3. 3. Sprint Review Meeting Open to stakeholders Live Product demonstration Product owner will decided if the acceptance criteria for the accepted PBIs have been met as in the Sprint planning meeting and if the goals have been met. Items which are not done will be moved back to the Product backlog. Lastly we will listen to the stakeholders product feedback which may result to new requirements for the PO to prioritize them according to his vision.

11.3.4. 4. Sprint retrospective meeting Inspect how the last Sprint went with regards to people, relationships, process, and tools Identify and order the major items that went well and potential improvements Create a plan for implementing improvements to the way the Scrum Team does its work. Status leveling techniques: a)Safety Check: b)Focused Conversation Principles: c)Basic retrospective d) Silent writing: Silent Writing is a technique implemented to hear out all the team members problems and then make decisions. e) Timeline retrospective: Write down your recollection of previous

11.3.5. 5. Backlog refinement meeting.