The Classical Software Lifecycle Project Practises and... · Software Project Practises And Management Alex Cummaudo SWE20003 7 Aug 2014 Quality Software Quality has diﬀerent stakeholder's

Software Project Practises And Management Alex Cummaudo SWE20003 7 Aug 2014

I. What is a Project?▸ A project is a temporary endeavour

- It has a definite beginning and end - Used to create unique product, service or result

▪ All projects are therefore unique and distinguishable ▪ Each project will concern itself differently (e.g., geographical location projects)

▸ SDLC Projects will have an order of macro and micro steps- Macro: Requirements Analysis; Design; Coding; Testing- Micro: Coding, unit testing etc.

The Engineering PerspectiveThe Classical Software Lifecycle

The classical software lifecycle models the software development as a step-by-step “waterfall” between the various development phases."

The waterfall model is often problematic because:!•  requirements must be frozen early in the life-cycle"•  requirements are validated late"

Design"Implementation"

Testing"Maintenance"

Analysis"Requirements"

Collection"

You have seen this before, in SDP!!

Winston Royce: http://www.cs.umd.edu/class/spring2003/cmsc838p/Process/waterfall.pdf

Iterative Development

Requirements "Collection"

Testing"

Design"

Analysis"Validation through prototyping"

Testing based on requirements"

Testing throughout implementation"Maintenance through iteration"

Design through refactoring"

Implementation"Boehm’s Spiral Lifecycle (cont.)

evolving system"

initial requirements"

first prototype"alpha demo"

go, no-go decision"completion"

Planning =" determination "of objectives, alternatives "and constraints"

Risk Analysis =" Analysis of "alternatives and identification/"resolution of risks"

Customer Evaluation =" "Assessment of the "results of engineering"

Engineering =" "Development of the "next level product"

Risk =" something that "will delay project or "increase its cost"

Source: Barry Boehm, A Spiral Model of Software Development and Enhancement, IEEE Comptuer, 21(5):61-72, May 1988

You have seen this before, in SDP!!

Scrum – an Agile Development Method

We will have a lecture on Scrum later in this unit.

Model Pros Cons Diagram

Waterfall ▸ Ok for well defined projects

▸ Ok for well scoped problems

▸ Ok for small problems

▸ Poor insight into how transformation between artefacts takes place

▸ Requirements are stuck and frozen

▸ Requirements validated late

Iterative ▸ Activities happen in parallel

▸ Iterate analysis design and implementation, not plan for a one-off go like Waterfall

▸ Needs an engaged and understanding client

Spiral ▸ Analyse risk at regular intervals

▸ Any model can be used at any “ring” of the spiral

▸ Takes longer than needed for some projects

UP ▸ Each phase has a key deliverable

▸ Good for macromanagement of phases

▸ Can produce a lot of unnecessary documentation

IECT

Scrum

� / �1 44


▸ Why develop software? - Resolve pain-points of a problem- Help to solve business goals- Social obligations- Benefit of new technology- Ultimately: Improve Business Value

▪ We choose projects that will improve value by the most▪ Software vendors will build products that maximise their profits

▸ Scoping: define out what needs to be done. Objectives must be set.▸ Planning: estimate and schedule resources. Split tasks and estimate time for completion

of each.- Estimation- Scheduling

▸ Organisation: Assign tasks to people, with dates ▸ Staffing: recruiting and motivating personnel ▸ Directing: ensure team acts as a whole▸ Monitoring (Controlling): detect plan deviations and corrective actions

The Management Perspective — Plan The Work Then Work The Plan

▸ Engineering Perspectives need to be appropriately managed for non-technical aspects- Budget, Time, Deadlines…

▸ To be a good project manager, you need to fail first: - Only when projects fail do you know what you did wrong

� / �2 44

Monitoring (Control)

Directing

Staffing

Organising

Planning

Scoping


- You never know when you are right!- Once you have failed, you have enough experience to know what not to do!

▸ Reasons why projects can fail - Over-scaled Projects: Too big and too varying a scope- Communication Breakdown: Lack of understanding between developers and clients - Poor Estimation and Planning- Unrealistic Budgets and Schedules - Inadequate Control Methods- Not enough focus on QA

PRINCE2 and PMBOK ▸ Project management frameworks

- Reminds us of phases and aspects in a project- Process Groups:

▪ Initiating—defining the scope & getting yourself set up

▪ Planning—planning your execution ▪ Executing—building the solution

▪ Monitoring & Controlling—measuring the quality ▪ Closing—finding out what worked well and what didn’t for next time

- Knowledge Areas of Project Management:

▪ Integration, Scope, Time, Cost, Quality, HR, Communications, Risk, Procurement

Forces and Concerns ▸ Conflicting project forces compete with each other▸ Stakeholders can only pick 3 of the 4 — the fourth is a consequence of the other three

� / �3 44

QualityHow Good?

TimeHow Long? Scope

What?

Cos

tH

ow m

uch?


Quality ▸ Software Quality has different stakeholder's perspectives:

- Users judge software on its fitness for purpose (functionality) and fault frequency - Developers will judge the software based on how easily we can adapt and improve it- Operation/Help-Desk judge software on how easily it can be installed and maintain - Managers judge software based on development cost and conflicts it causes in org.

▸ Conformance to:- functional and nonfunctional requirements- documented development standards- implicit characters that are expected of software

Scope & Objectives ▸ Objectives: Qualitative General goals of the project, but not how they will be achieved▸ Scope: Quantitative primary functions of the software, and range of things project should

consider▸ Goals: realistic and measurable values that can be measured and thus controlled

- Constraints, performance reliability must be factored- Customer must set priorities so that some goals are elevated over others▪ It’s impossible to fulfil every goal! We fulfil some more than others…

4-Step Guide To Projects ▸ ( I )nception

- Understand the problem

▪ Basic understanding- Define objects, scope and constraints▪ Psuedo-constraints: must interface with pre-existing system (e.g., you must use Java)

- Business Analysis▸ ( E )laboration

- Feasibility Analysis

▪ You know a bit about the idea of the problem▪ More detailed analysis of the problem now that we know what it is▪ Is it doable?

- Identify possible solution directions▪ Which has a higher chance of success?▪ Which has the most profit?

▪ Which costs less?- Select a potential solution

▸ ( C )onstruction

� / �4 44


- Plan the solution- Developed detailed project plan- Allocate tasks to people- Organise HR

▪ How many testers do we need etc?- Execute and closely monitor

▪ Make sure we don't get sidetracked▪ Risk manage as we go along

▪ Avoid scenarios that can have a harmful impact to the project▸ ( T )ransition

- Close off the project- Work out what worked well, what worked bad- Deploy the system into the working environment

Project Management Plan ▸ 4 Core Functions

- Scope Management

▪ What is required of the project?▪ What tasks do we need to get done?

- Time Management ▪ How much time do we need for each of the tasks?▪ Once we know time, then we can begin time management and allocation

- Cost Management ▪ Ensure working within budget

▪ Must conform to budget estimates and profit estimates- Quality Management ▪ Ensure our product is good quality▹ Quality of the infrastructure of AMDC building ▹ Timing of the project (e.g., constructed by end of 2014)

▪ What can you promise to your customer?▹ This must be measured precisely and quantitatively ▹ So that you and your client can precisely agree on what is "quality"

▸ 4 Facilitating Functions - HR Management

▪ Effective management of people and their skills- Communications Management

▪ Clients

� / �5 44


▹ Communications with the customer/client▹ Client liaison—keeping lines with customer

open▹ Negotiate with customers project deadlines

(e.g., if you are running behind)▫ How well can you negotiate with your

client? ▫ Can you do it without penalties?

▪ Team Members ▹ Use the WBS (Work-Breakdown-Structure) to work out which major tasks each

person need to work on▹ Project Scheduling is the communication tool ▹ Think:▫ What tasks do we need to do? What are their dependencies?▫ How many days do we have to do

them?▫ Who is going to do these tasks?

▹ List tasks, identify relationships and schedule the tasks▫ Make network diagrams to organise

the tasks and work out a schedule▹ What are the steps? ▫ 1. Develop the WBS and identify the discrete tasks that need to be done▫ 2. Identify relationships between the tasks▫ 3. Estimate the duration needed to finish the tasks▫ 4. Schedule each task in order

- Risk Management

▪ Identify knowledge gaps▹ Spike each of the gaps as early as possible

▪ Failsafe the assumptions you have made▹ Make sure your assumptions (i.e., things you assume things will run smoothly)▹ What happens if something happens? What should we do? ▹ Fred, the only Prolog programmer, gets hit by a truck. What are our options?▫ Hire another Prolog programmer?

(But this will require us to train him in problem domain)▫ Train another employee to use Prolog?

(But this will mean we have to allocate time away from the problem domain)� / �6 44

Project Scheduling

List tasks Identify Relation-ships Schedule the tasks

1.  Develop the WBS – identify the discrete tasks that need to be done (see later)

2.  Identify the dependencies between these tasks

3.  Estimate the duration needed to complete the tasks

4.  Schedule the tasks in order

Project Scheduling

List tasks Identify Relation-ships Schedule the tasks

1.  Develop the WBS – identify the discrete tasks that need to be done (see later)

2.  Identify the dependencies between these tasks

3.  Estimate the duration needed to complete the tasks

4.  Schedule the tasks in order


▹ Think ahead of schedule!- Procurement Management

▪ Buying hardware

▪ Getting resources together for our project▪ Setting up vendor contracts that will support our project

▸ Project Planning - Split the projects into tasks using SDLC as an anchor- Create a WBS (Work-Breakdown-Structure)- Estimate the time needed to complete the task

Work Breakdown Structure ▸ Stage your releases of the project into major tasks and subtasks

- By breaking the work down we are able to manage it better- Think: Functional Decomposition

▸ Measuring and collecting data as we go along- Helps us verify that we are on track and to monitor our project

▪ Schedule this at regular intervals - Key Terms:

▪ Milestone ▹ endpoint of a smaller activity▹ output that shows the completion of an activity

▪ Deliverable ▹ project result that is either delivered to customer▹ produced at the end of a major project phase

▪ Deliverables > Milestones▹ A milestone may not be a deliverable▹ A deliverable may be a milestone

▸ Each WBS leaf should be able to be completed within several hours of work▸ Different approaches:

- Activity Based Approach

▪ Look at main activities need to complete in order to finish project▹ Break down the main activities into smaller activities▹ Break down until the leaf tasks can be completed with acceptable efforts

▪ High level and applicable to many projects

▪ Similar to waterfall

▪ Pros:▹ Non-overlapping activities

� / �7 44


▹ We can redefine the scope as we go along▹ Ready-to-go basis for new projects▹ Easily communicate to client

▪ Cons:▹ We could miss a product (i.e., focus on the tasks not products)

�

- Product Based Approach

▪ Focus on the different things that needs to be produced▹ e.g., the SRS, User Manual, Inventory Database etc.▹ The focus is on what the products are, not HOW we will do it

▪ Danger is that dependence between products is missed

� - Hybrid Approach

▪ 1. List of products the project will deliver

▪ 2. Tasks needed to realise those products

Timing Estimation ▸ Assign a duration to each task in the WBS

- 1. Work out the size and complexity of a given task- 2. Use this to estimate the effort required - 3. Depends on the number of people available to do the work

▸ Time & Effort - People do not work 100% productively- Consider interruptions, socialising, emails etc.

Activity-based Approach – Example

Software project

Requirements Analysis

System Design Coding Testing

Data Design

Process Design

This is a very generic decomposition at a high level, applicable to many projects using a waterfall approach Product-based Approach – Example

Inventory Control

Inventory Databases

Item Processing

Management Reporting

Item Database

Vendor Database

Item Addition

Item Deletion

Item Modification

Item Purchasing

Item Sales

Invoicing subsystem

Sales Order Processing

Item Reporting

Sales Reporting

Danger is that dependencies between products is missed

� / �8 44


- Key terms:

▪ Real Time: People usually work at about 70% productivity

▪ Ideal Time: Fully productive time without interruptions

▪ Ideal Effort: Amount of ideal time to complete a task ▪ Real Effort: Amount of real time taken to complete a task

▸ Use past experience to estimate how much time it will take on each task▸ Scheduling Techniques

- Time Boxed

▪ The time will determine the scope▪ The time is fixed—choose a scope that will fit in this box

- Activity Based

▪ The scope will determine the time▪ The work is fixed—choose a time such that all tasks will be completed

Risk Mitigation ▸ What are risks?

- PMBOK: "an uncertain event or condition that, if it occurs, has a positive or negative effect on a project’s objectives."

- PRINCE2: "the chance of exposure to the adverse consequences of future events." ▸ Look at what can go wrong for each task in WBS

- Help plan for risk mitigation▸ Risk Drivers (KoST)

- Knowledge Gap

▪ We don't know something about the problem domain

▪ We can't work out something in the context of the system- Skill Gap

▪ Inexperienced team members in skills to develop system- Technology Gap ▪ Is the technology mature enough for what we want to do?

Scoping and Planning▸ Focus on planning the work

Problem Identification ▸ Define what is currently happening

- Pain Points▸ Define Problem Domain vocabulary

� / �9 44


▸ Define objectives and goals- Objectives: High-Level Goals

▪ very high level!

▪ general goals of the project▪ does NOT define how these general goals will be achieved

▪ usually business goals

▪ need to be SMART: realistic and measurable ▹ Specific ▹ Measurable achievement ▹ Achievable ▹ Realistic ▹ Time Terminated (Bounded)

- Scope: Low-Level Tasks

▪ Primary functions that the software should have—think Functional Requirements

▪ Bound these functions in a quantitate manner

▪ Identification of user tasks ▹ A list of tasks, but not an elaboration of details▹ Not a full requirements specification

- Constraints: Restrict possible solutions

▪ Not usually negotiable▪ A constraint is essentially a requirement that limits your options

▪ Can think outside the box, but not outside the constraint ▸ Deciding on a solution

- Identify problem domain and the type of system needed- Use the project forces (CTSQ) to help move in a direction- Apply Objective Criteria to help▪ Risk analysis—failsafe alternates▹ KoST analysis

▪ Cost-benefit analysis—best value for client?

▪ Feasibility analysis—is it even possible?- If you still cannot make a decision:▪ Gather more information

▪ Choose a solution that you fancy as long as its no extra cost to the client▸ Planning & Scheduling

- Make a WBS by splitting the tasks down▸ Estimation

- Assign durations to each WBS task� / �10 44


▪ Estimate the size and complexity of the task

▪ Relate size and complexity with effort and time

▪ Base likely duration on past experience and analytical knowledge

▪ Effort Estimation: ▹ Historical Data▹ Expert Advice▹ Analogies▹ Algorithmic Models▹ 3 Point Technique = (worst + 4 * most likely + best) / 6 ▹ Delphi Technique ▫ Exploit the knowledge in project team▫ Get all experts together to summarise and aggregate their estimates

▹ Velocity▫ Agile concept▫ Measure the value delivered in a time-bound iteration▫ Burn-down the progress

Scheduling

▸ Schedule to organise- project activities into a coherent order- staff allocations to activities to ensure project is completed in minimum time

▸ Use the activities in the WBS to help plan your schedule- Define the activity▪ Estimate resources

▪ Estimate duration- Identify dependencies in activities- Develop a schedule and control it

Activity Sequence Table - interdependencies between:

▪ activities in the WBS

▪ product descriptions▪ assumptions

▪ constraints - With the Sequence Table we can then

determine a realisable Schedule

� / �11 44

Example - Activities and Dependencies

Id. Activity Name Dependencies

A Hardware Selection and Delivery

B Hardware Installation A

C Legacy System Analysis

D Software Design C

E System Implementation and Testing B,D

F Data Migration C

G System Deployment E,F

H User Documentation

I User Training H 12

Here “X depends on Y” means that Y must be completed before X starts.

Project to replace a legacy system – very high level WBS


Schedule Development ▸ Develop a Realistic Project Schedule▸ The Schedule Should Include:

- Major Activities- Milestones - Deliverables

▸ May require several iterations▸ Scheduling methods: Critical Path Method, Critical Chain Method, Gantt Charts ▸ Scheduling Factors:

- Availability of resources- Allocation of resources- Staff skills and responsibilities (labourer skills vs supervisor skills & respons.) - Project Monitoring- Cash-Flow Forecasting (will we have enough funds at this stage?)- Constraints!!!

▸ Scheduling Techniques - Predictive (Traditional)

▪ Scope is static and does not change much▪ Well understood problem and solution domains

▪ Activities are well detailed and plannedThey can be done upfront and for the entire project duration

▪ Activities, dependencies, risks (mitigation) are clearly defined

▪ Staff available whenever an activity is due to start▪ Activity-Based Techniques ▹ Fixed work/scope to be completed (final year project)▹ Time is dynamic▹ Define and allocate resources/time so that all scope tasks can be completed

- Adaptive (Agile)▪ High-Level project goals are defined; scope is subject to change

▪ Murky problem and solution domains

▪ Activities are planned on a short-term basis

▪ Risks are managed on-the-spot (dynamically)

▪ Time-Boxed ▹ Fixed time that is available▹ Scope is dynamic▹ Define a scope such that it can be completed within this time slot

� / �12 44


Critical Path Method (CPM) — Predictive ▸ Schedule all activities so that they can be completed as quickly as possible▸ Identify time-critical events

- Events are those which delay the entire project completion if they are delayed▸ ACTIVITIES ON NODES METHOD: How to calculate

- Capture activities and their interrelationships using a graph

▪ Each node represents the activity, dependent on each other activity via an arrow:

▪ For each activity/node, calculate▹ Forward Pass: Earliest Start Time (EST) and Earliest Finish Time (EFT)▫ EST = max( EFT(preceding nodes) )▫ EFT = EST + AD

Forward Pass Example

� / �13 44


▹ Backward Pass: Latest Start Time (LST) and Latest Finish Time (LFT)▫ End Node, f

LST(f) = LFT(f) = EFT(f)▫ LFT = min(LST(preceding nodes))▫ LST = LFT - AD

� ▹ Slack Time = LST - EST▹ Critical Node = LST == EST / LFT == EFT

▪ Identify the Critical Path and the Critical Events▹ Critical Events are those which have a Slack Time of 0▹ That is, you have 0 time to be slack on this task! ▹ The LST is the same as the EST

▸ ACTIVITIES ON ARROWS METHOD: How to calculate- Activities are represented by arrows, not nodes- The nodes represent commencement and termination of these activities- AD is on the arrow, not on the node…

▸ Critical Path - There may be several critical paths- The critical path indicates the shortest time for completing the project

▪ Any activity on the critical path mustn't be delayed▪ Whenever an activity is delayed longer than slack time, the critical path should be

recalculated

� / �14 44


Critical Chain Method (CCM) — Predictive ▸ CPM does not factor in allocation of HR to tasks

- E.g., task A and B can be done in parallel (i.e., they are independent)However, only one HR can divide his or her time to the task—thus disallowing parallel commencement

- CPM only considers task dependency constrictions, not HR dependency constrictions

▪ i.e., for staffing reasons, tasks cannot be done in parallel ▸ CCM is another activity based method, like CPM

- Extends CPM with contingency buffers - Factors HR dependency constrictions- Example:

1. Peter is allocated to A1 and C2; A1 is scheduled to finish after C2 begins—Conflict!2. John is allocated to C1 and B1; C1 is scheduled to finish after B2 begins—Conflict!

� / �15 44


PERT (Program Evaluation and Review Technique) — Predictive ▸ Makes a single value estimate from the best, most likely, and worst case scenario

- It is this value you will then use in your planning.▸ Standard technique to seek expert guidance on

- Best Case: The optimistic time of completion = b- Most Likely: The most likely time of completion = m- Worst Case: The pessimistic time of completion = w- = ( b + 4m + w ) / 6

▸ Often, best, most likely and worst case are not of equal distance from each other- i.e., worst case is most likely much further away than best case

▸ Example:We predict that we will procure the trollies in a week most likely, two weeks at most. If we're lucky then perhaps within 5 days.Best Case = 5 days, Most Likely Case = 7 days, Worst Case = 14 daysTherefore, PERT = ( 5 + 4(7) + 14 ) / 6 ≅ 8 days

Therefore, plan for 8 days

Gantt Chart — Predictive ▸ Graphical illustration of:

- the project calendar- activities from the WBS, their start and end dates, durations and slack times- optionally, the people allocated for each activity- optionally, the current completion of tasks in the project

▸ Derived from a schedule that has already been completed- e.g., do a CPM or PERT analysis, then a Gantt Chart

▸ During a project, the PM would- update the chart to update status- assess if there is any delay that will affect the entire project- reschedule activities to meet deadlines

� � / �16 44


Iteration Planning — Adaptive ▸ Three levels of iteration planning

- Initial Scope▪ Understand the domain

▪ Build spikes

▪ Identify possible risks- Release Planning

▪ Prioritise the feature list as defined by customers▹ Remember, it's adaptive—we can change with customer needs

- Iteration Planning

▪ Once an iteration starts, requirements will be frozen until the end of that iteration▹ Customer will select the tasks/features to be implemented in this iteration▫ Some tasks can be considered as a "base story" ▫ A base story is = 1 unit of time▫ Other tasks may be stated as a multiple of this base story

▹ Customer provides the business value and priority for the task/feature

▪ Detail estimates and selection of features for each iteration▹ Development Team will provide estimates for delivering these task/features▫ With each "base story", a time estimate required for its completion is made

▫ This is known as that story's velocity:

E.g., 15 hours per story unit is the rate of progress on this task

▪ Plan for current iterations based on feedback from previous ones▸ Velocity gives good estimates on how productive the team is

- The team can then estimate what they can and cannot promise for the next iteration

Quality Metrics

▸ Use metrics to track whether we are ahead or behind.▸ Remove subjectivity from your quality—they need to be tied to quantitate values▸ Measure: A function which has a domain of all software artefacts ▸ Metric: A type of measurement which is somehow related to a software system. ▸ Measurement: A value assigned to an artefact by the measure▸ That which you can measure you can control:

- What do we want to control?

▪ Cost and work effort▪ Quality

▪ Identifying where to concentrate resources� / �17 44


▪ Assessing how well a project is progressing- Why control?▪ Improve productivity▹ do things faster and better

▪ Improve software quality▹ Number of errors: behaves unexpectedly▹ Defects: bugs and bad documentation▹ Usability

▪ Improve reliability▹ The software "shouldn't broken"▹ For bad input, the program can still run

▪ Indicators of work and cost

▪ Evaluate methods, tools and practices- Software Metrics

▪ Metrics must be useful: there is no point if the metric has no meaning▪ Examples:▹ LOC ▹ Cyclomatic complexity of a particular method ▹ Amount of nesting in a loop▹ Number of person-days required to implement a user story ▹ Programmer productivity

Includes comments and readability of code(LOC / time)

▹ Requirements stability How often to the requirements change(#initialReqs / #totalReqs) / time

▹ System spoilage(effort spent fixing faults / total project effort)

▹ Usability issuesTime taken on average by users to complete data entry on a screen

▸ Precision - To be precise in your measurement, you need to specifiy:▪ Domain: exactly what are we measuring?

e.g. the number of errors found per 1000 lines of code

▪ Range: What are the units of measurement? non-negative integers

� / �18 44


▪ Mapping Rules: What guidelines apply to the measurement?ignore the comments

▸ Fog index is how foggy the literature is due to complex words- 0.4 ✕ ((#words / #periods) + (#complexWords))

Where complexWords is words with syllableCount >= 3(excludes prefixes/suffixes -ing, -s, -es etc.)

▸ Validity and Reliability - A good measure is both valid and reliable- Valid: measures what it is intended to measure - Reliable: yields consistent results (i.e., measure by different people/different times)

▸ Direct vs Indirect Measures - Directly observe the measurement

▪ LOC - Indirectly calculate the measurement▪ Calculated from direct measures

▪ Defect Density = # Defects / LOC ▸ Scales of Measures

- Nominal — Non-Ranked Mutually Exclusive Categories

▪ Stats into mutually exclusive categories: Languages: Obj-C, C++, C#, PHP

▪ No rankings between categories (don't compare them)- Ordinal —Ranked Non-Fixed Separated Categories

▪ Similar to nominal scale but comparable categories▪ Non-fixed separation▪ Minor Error, Marginal Error, Major Error, Catastrophic Error

- Interval — Ranked Fixed Separated Categories ▪ Fixed separation between values

▪ Normal statistics permitted; work out sum, mean etc.

▪ Final Marks in SDP: HD (80), D (70), C (60), P (50)

� / �19 44


- Ratio — Value Scales

▪ Permits scaling

▪ Requirement Stability (%) = Initial Requirements / Total Requirements - Absolute — Value ▪ Counting the number of elements in the entity set

▪ Number of Developers - Choosing a measure

�

Code Size Metrics ▸ Lines of Code

- Ambiguous for small projects - A poor indicator of productivity

▪ Ignores software reuse, code duplication, benefits of redesign▪ The lower level the language, the more productive the programmer!

▪ The more verbose the programmer, the higher the productivity!

▪ And yet – if there is historical data for the programmers / team, it may be quite useful. - Still useful for defect densities

▸ Function Points - More sophisticated measurement than LOC- Focuses on counting inputs and outputs for a function

▸ Object-Oriented Systems - Aims to estimate number of classes, and objects constructed, and methods (and their

inputs and outputs)

Complexity Metrics ▸ More complex components are more likely to contain errors

- hence, they need more attention in verification- research shows that a method with greater cyclomatic complexity has more errors

▸ Cyclomatic Complexity - An indicator of possible issues- Control Flow Graphs (CFG)

� / �20 44


▪ Visual representation of how the flow of control will go

▪ Simplify the entire program structure and make it into a visual digram▹ Take away unnecessary implementation details▹ We want to see looping and branching (i.e., selection statements)

▪ Find all possible paths and test each possible path

�

▪ v(G) = e – n + 2 = 1 + r ▹ e = #edges ( lines )▹ n = #nodes▹ r = #regions▹ Paths are the different possible paths based on input data▫ Use a test case that matches EACH POSSIBLE BASIS PATH ( = region )

e - n + 2 (no edges - no nodes + 2)e = 6 (Each edge is a line…)n = 5therefore Paths = 6 - 5 + 2 = 1 + 2 = 3 (and hence there are the 3 paths above!)

▸ Measure of OO-Metrics

� / �21 44


� ▸ Coupling Between Objects—CBO

- number of other classes a class requires to compile- higher CBO means significant object interactions

▪ this indicates greater complexity ▸ Lack of Cohesion Metrics (LCOM)

- not accessing same attribute in local methods

Programmer Productivity ▸ Measure of the rate at which individual developers

- size-related measures based on some output from software processes

▪ Real-time embedded systems, 40-160 LOC/P-month ▪ Systems programs, 150-400 LOC/P-month ▪ Commercial applications, 200-800 LOC/P-month

- All metrics based on volume/unit time are flawed ▪ they do not take quality into account

Skewed Statistics ▸ Use standard statistics to summarise the numbers…

- The mean, the median and the mode are used to identify a single “typical” item- The standard deviation measures the “spread” of the items- The mean and standard deviation are useful when the distribution is symmetrical

▸ However, software metrics are typically asymmetrical:

� / �22 44


� ▸ So what can we do with these skewed statistics?

- Use a cumulative percentage instead, which can be used on skewed metrics

Software Quality▸ Do we actually satisfy the quality of the system which we're delivering?

- This is the quality we propose we will agree with out clients- At delivered date, you should have no excuse to not pay me if I meet our quality targets- A way in which we can protect ourselves from the client

▸ Quality Management - Collecting data to define the quality of your software- Does it satisfy the quality metrics we defined/agreed with our clients?▪ Do we need to improve?

▸ Split software quality into relevant aspects:- Then you can use metrics to measure characterises

▸ Define metrics to measure quality using GQM - GQM: Goal - Question - Metrics

▪ Goal ▹ Define the goal▹ How effective is the coding standard to Ruby?

▪ Questions ▹ Break down into questions▹ Who is using Ruby? What is productivity/quality with/without Ruby?

▪ Metrics ▹ Proportion of developers using Ruby ▹ Judgement of their experience with Ruby ▹ Ruby code size, complexity, robustness

� / �23 44


▸ Quality Perspectives - External ▪ Derived from the relationship between the environment and the system

▪ A client-side perspective on their expectations of the final software▹ How well the software performs?▫ Does the BMW drive fast? ▫ Software's response time to input?

▹ How well it meets user expectations?▫ Is the BMW as luxurious as I expect? ▫ How good the software looks and how easy it is to use?

▹ How well it meets all the specifications it needs to accomplish?▫ Can the BMW move from A to B? ▫ Does it achieve the software's goals?

- Internal

▪ Derived immediately from the product description: ▪ Development perspective on how well the technologies are being used/implemented▹ "Never use the latest technology" because it is typically unproven▫ How well it is built?▫ How well is it designed? ▫ How easy is it to repair/maintain?▫ Does it use the latest technology?

▪ Think: good internal quality more likely to lead to good external quality - Process Build Quality

▪ The quality of the construction/manufacturing process ▹ What does it cost to build the system?▹ How long does it take?▹ How predictable is the process?▹ Does it deliver good software at the end?▹ Does the approach to coding result in fewer errors?▹ Does it deliver outcomes efficiently and effectively?▹ Calibration of car assembly machines together

▸ Defining quality - ISO

"The totality of characteristics of an entity that bears on its capability to satisfy stated or implied needs"

- Quality can't be subjective—it must be measured- Conformance to…

� / �24 44


▪ Product Quality: Explicitly stated functional and non-functional requirements

▪ Process Quality: Explicitly documented development standards

▪ Implicit standards that is expected of all professionally developed software- Fitness for use - Think: If we have a good process quality then we should have a good product

▪ Not using an IDE vs. using an IDE…▸ Problems with Software Quality

- Good quality ≠ reduced defects - Specifications may be incomplete and inconsistent

▪ Changes quite often - Tension between:

▪ customer quality requirements (efficiency, reliability)▪ developer quality requirements (maintainability, reusability)

- Quality requirements are hard to specify

▪ Directly measurable (errors/LOC)▪ Indirectly measurable (usability)

Software Quality Models McCall's Model

▸ A way which we can link up Developer's Views (internal) from the User's View (external)- We can trace ways in which we did that development thing back to the user's view

� / �25 44


- E.g., why did we make it efficient? Because we wanted to make it reliable… etc.- Note Consistency Context: Consistently Correct Outcome AND Consistent Reliability

ISO Model ▸ A divide and conquer approach to quality▸ Keep breaking down until we can measure something▸ Look deeper into the key issues related to the quality of the software

- Start with Quality- Break quality down into Factors (Attributes)▪ FURP ME

Functional, Usability, Reliability, Portability, Maintainability, Efficiency- Break factors down into Characteristics (Sub-attributes)

▪ E-SCAMError Prone, Simplicity, Consistency, Accuracy, Modularity

- Break Characteristics into Metrics- Break Metrics into Thresholds (if applicable)

�

� / �26 44


Quality THINK Description

Correctness External Does it do what I want?

Extent to which a program satisfies its specifications and fulfills the user's mission objectives.

Reliability External

Does it do it accurately all of the time?

Extent to which a program can be expected to perform its intended function with required precision.

Efficiency External Will it run as well as it can?

T h e a m o u n t o f c o m p u t i n g resources and code required by a program to perform a function.

Integrity External Is it secure?

Extent to which access to software or data by unauthorized persons can be controlled.

Usability External

Can I figure out how to run it?

Effort required to learn, operate, prepare input, and interpret output of a program.

Maintainability Internal Can I fix it? Effort required to locate and fix an

error in an operational program.

Flexibility Internal Can I change it? Effort required to modify an

operational program.

Testability Internal Can I test it?

Effort required to test a program to ensure it performs its intended function.

Portability Internal

Will I be able to run it on another machine?

Effort required to transfer a program from one hardware configuration and/or software system environment to another.

Reusability Internal

Will I be able to re-use some of the software?

Extent to which a program can be used in other applications - related to the packaging and scope of the functions that programs perform.

Interoperability Internal

Will I be able to interface it with another system?

Effort required to couple one system with another.

Robustness Internal

Will it perform well under stress?

The degree to which a system continues to function in the presence of invalid inputs or stressful environmental conditions.

� / �27 44


Why Use Models? ▸ Not all factors will apply to your project▸ But those that do can help you apply insight into quality:

- How is "quality" specified for the factor? (i.e., characteristics)- What measurements can be taken for this quality? (i.e., metrics)- What are acceptable measurements? (i.e., thresholds)

▪ If we go over our thresholds, then we don't satisfy quality!!!- How do we develop our software so that it is quality from the get-go, rather than going

back and fixing up poor-quality factors?

▪ Do we weight/prioritise our quality factors?

Quality Control ▸ How we manage quality to deliver high quality systems

- Upkeep quality reviews- Suitable monitoring to check quality in development- Following good practises

▸ When Internal/Process quality is well controlled during the project…- …this usually leads to high External/Product quality obtained when delivered:

▸ Develop a Software Quality Assurance Plan (SQAP) in the Project Plan- Defines the desired qualities of your end product

▪ What is the most important quality attributes? - Defines the quality assessment process▪ How will we measure and control the quality?

- Sets out which processes/standards should be applied to get high quality- QA Reviews▪ Reviews—Question what we have!▹ Inspections for defects (for Product)▫ Checklists on detecting errors, requirements mismatch, following standards

▹ Progress Review (for Product and Process)▫ Budgets/Plans/Schedules on whether project runs on time, milestones, process

and product review

� / �28 44


▹ Quality Review (for Product and following Standards)

▪ Outcomes▹ No Action: Everything is okay▹ Repair: Developer may need to correct a fault▹ Reconsider Design: Product is severely incorrect

▸ Audits - Another team (usually external) examines whether or not you are adhering to SQAP- Have you been doing reviews? Have you following SQAP? Where are your reports?

Extreme Programming (XP) ▸ Follows the 12 principles with regards to Product, Process, Teamwork, Coding…

- (Boxed principles relate with design…)

Product & Process Standards ▸ Project Standards—characteristics that all components of the project should exhibit▸ Process Standards—how software processes should be enacted

� / �29 44


Risk Management

What are Risks? ▸ Uncertain events have a negative impact on a project's objectives being successful

- Risks relate to the future - Risks involve cause and effect ("why" and "measurable consequences")- We don't know its likeliness of occurrence—they're uncertain!

▪ It could be very likely—a disgruntled team member leaves

▪ It could be very unlikely—a talented team member dies▸ Two main kinds of risks:

- Project Risk: PM's Risk

▪ A risk which threatens a project's cost and schedule - Business Risk: Senior Management Risk

▪ A risk which threatens the viability of the software to be built▹ E.g., a product no one wants, product doesn't fit with business strategy etc.

Risk Management ▸ RM = Identify Analyse and Respond to risks

- Positive Impact On:

▪ Helps us select projects▹ Why should a project not be selected?

▪ Helps us determine the scope of projects (risks scale scope)

▪ Helps us develop schedules and estimates▸ Mitigation helps reduce the impact of any risks that have happened

- A team member leaving:

▪ Team members share knowledge on a certain aspect of the project ▪ By sharing knowledge, teammates learn off each other

▪ By learning off each other, the knowledge is now shared ▸ IDENTIFY

- What might happen?

▪ Hazards ⇛ Problems ⇛ Risks

▹ Hazards are events that might occur, and will create a problem▹ A problem will have a negative impact if it does occur▹ ∴ Hazard's, if realised will become problems, which are thus risks.

▹ Examples of hazards:▫ Unproven technology▫ Unclear requirements

� / �30 44


▫ Lack of experience in a problem domain▫ Over-scoped/complex problem

▪ Identify both the cause and affect of the issue

▪ Aggregate a checklist of potential hazards over many projects- This can be very generic—anything can happen!▪ Remember KoST gaps come in handy here!!!

▪ This is known as RISK DRIVERS! ▸ ANALYSE

- What are the causes of this risk?

▪ KoST Skill Gap Analysis (in our control):▹ Problem Framing

Have we solved the wrong problem!? Are we developing the right software? V&V!!! ▹ Problem Approach

Have we approached our methodology, resources and processes okay?

▪ Outside of our control: ▹ Budget + Personnel

Have we enough money and resources in this project?▹ Morale + Poor Team Dynamics

Do our developers even care about what they're making?▹ Business

How well does the business market the software? Commitment to the software? Post-software development made by senior management…

- What is its likeliness?- What is the impact of the risk?- What is the priority of this risk?

▸ RESPOND - How do you respond to that risk?- How do you monitor the risk isn't near?- How do mitigate that risk?- How do you minimise the impact?

Top 10 Risks ▸ Personell shortfalls▸ Unrealistic schedules/budgets▸ Developing wrong software functions + UI

- Lack of communication (internally and externally)▸ "Gold plating"

� / �31 44


▸ Constant requirement changes▸ Bad externally executed tasks▸ Shortfalls in externally furnished components▸ Realtime performance shortfalls▸ Straining technology▸ Lack of resources and time for testing▸ Lack of trust▸ Incorrect deployment platform (from development platform)

Portability is important!

Estimation and Prioritisation ▸ Quantify the risk using metrics

- Pros: We have a quantitate way to assess and rank risk- Cons: Subjective—where do the numbers come from? Risks may also be dependent

▸ Probability = rate of occurrence - UX Data- Ranking Criteria (Low Medium High etc.)

▸ Impact = severity of consequences - Units of Impact- Ranking Criteria (Insignificant, Tolerable, Serious, Catastrophic)- Can be measured in Dollar Units- i.e., the impact will be $100,000

on the business ▸ Exposure = Probability ✕ Impact

The exposure of a risk (how deep it will affect us) first depends on how probable it is, and then the impact it has on the project.

▸ We can use exposure to rank our risk items - Ranks are baed on exposure—this shows the order of importance for the risk- However, risks are not static—they can change

▸ Cost of action - Risk management costs us money!- Perform a cost-benefit analysis to see if mitigation is worth the risk- Is it better to spend $500 on mitigation to prevent a risk with an impact of $100?

▪ Usually look for alternatives

� / �32 44

Risk Estimation – Example 2 (cont.)

Low (1)

Moderate (2)

High (3)

Very High (5)

Insignificant (1) 1 2 3 5

Tolerable (2) 2 4 6 10

Serious (3) 3 6 9 15

Catastrophic (5) 5 10 15 25


▪ Otherwise carefully monitor the risk

Risk Mitigation ▸ Types of Mitigation Strategies

- 1. Risk Prevention/Avoidance

▪ Prevent the risk item from happening in the WBS▪ Using an unknown technology can be prevented by using a known technology

▪ Unclear requirements can be prevented by using formal requirement spec. docs - 2. Likelihood Reduction▪ Ensure that there is zero chance that this risk item can occur

▪ Choosing wrong technologies can be mitigated using spikes/prototypes

▪ Declining team morale can be amended using free coffee, BBQs etc. - 3. Impact Reduction

▪ Reduce the consequences the risk has on the project

▪ "Hit by a truck" factor reduced by distributing knowledge amongst the team ▪ Get two development teams to work on the same project

- 4. Risk Transfer

▪ Outsource a high-risk component and let others deal with it (CONTRACTS!)▪ Contractual agreements that someone else is guaranteed to take the blame if they

stuff up - 5. Contingency Planning▪ Entirely new planning strategies where risks cannot be avoided

▪ These risks need careful monitoring!

▪ Hire agency/offshore programmers where a team member is ill

� / �33 44

Risk Reduction Strategies – Example Risk Item Strategy Category

Database performance Invest on a higher-performance DBMS Hazard

prevention

Staff lack of skills Outsourcing, staff training, buying components Likelihood reduction

Defective components

Replace potential defective components with bought-in components of high reliability

Risk avoidance

Underestimate development time

Outsourcing some components to contractors or agency Risk transfer

Organizational financial problems

Prepare a briefing report for senior management showing how the project is making a significant contribution to the goals of the business

Contingency planning

Adapted from Fig. 5.13 (Sommerville, 2007)


Agile▸ Iterative software development

- Empirically controlled▪ control as you go

▪ constant improvement and priority/risk driven- Focus on maximising business value

▸ Empirical process- Treat the development process as a black box - Development starts with a best estimate at what will work- The process is then regulated day by day and is adjusted if needed - Process is▪ not well defined

▪ based on previous learning experiences

▪ knowledge is used as a guidance for moving forward▪ not a repeatability of past actions

▸ Requires trust from the client

� / �34 44


Scrum Roles ▸ Product Owner (Raj)

- provides vision- provides return on investment- determines when product is "ready to release" in production

▸ Scrum Master (Al) - owns the development process- determines what project-level decisions need to be made- motivates, coaches and guides the team- ensure team stays on track- delivers the vision with the given constraints- ensures the team has all that it needs to deliver a product

▸ Scrum Team Member (Me!) - plans tasks- responds to commitments made- works day-by-day to achieve the focus that's been set- responsible for delivering functionality

Scrum Terms Backlog

▸ The primordial "soup" - features- architecture- defects- quality attributes- constraints

▸ Everything is being accessed necessary to project completion—anything and everything- owned by the Product Owner- estimates for each item in the backlog are proposed by the Product Owner- team assists in the estimation of these efforts

Sprints ▸ Once the backlog is ready and estimates made, we begin a sprint▸ The sprint is a current iteration of work which addresses backlog items (sprint backlog)

- Once the sprint has begun, the backlog shouldn't change- A sprint lasts for about 30 working days (1.5 months)- Team is self-organised under the Scrum Master (Al) - Team expands upon backlog tasks into subtasks and gets to work on them

� / �35 44


▸ Before a sprint starts…- Product Owner, Scrum Master and team meet up to prioritise functional requirements- Team identifies the best set of functionality they can deliver

▪ Choice is made that maximises business value (i.e., sprint backlog)- Ends in a short presentation (standup) outlining the commitment from the team

▸ After a sprint ends…- Team reviews the sprint and identifies what they have learnt from it (a standup)- Like the initial standup, but done in the previous iteration- Can include a sprint demo of the work that has been made

▸ Managing sprints- Burn-down charts help indicate the velocity and estimated time remaining left on the

project- A number of sprints is generally taken before a product is released—this helps keep

track of that

Daily Scrums ▸ A standup meeting, where everyone answers:

- What did you do since the last scrum?- What will you do until the next scrum?- What prevented you from doing work?

▸ Increase transparency—no discussions▸ Held at the same time at the same location—get team members in the habit▸ Scrum Master alleviates why people couldn't do any work (question 3)

Scrum Challenges ▸ Need good, effective managers

- Need to be able to make quick, positive changes- Must consider both qualitatively (burndown) and quantitatively (team whatchaydos)

▸ The TEAM makes decisions traditionally made by managers- Managers are not generally encouraged to lead by making decisions for the team- The team is involved for making their own decisions

▸ Not everyone is able to accept responsibility for their own actions▸ Lots of transparency makes it hard to "blame"▸ Not everyone is comfortable making decisions ▸ Not useful in:

- high-risk or non-dynamic (i.e., stable requirements!) projects- safety-critical systems- very large teams- fixed-price and fixed-time projects

� / �36 44


Scrum Benefits ▸ A Transparent development process ▸ Far more productive development process (once transitions made)▸ Slow, but continuous improvement▸ Accepts the fact that software development is NOT predictable, stable and repeatable

- PROGRESS is still made even when REQUIREMENTS CAN CHANGE - Constant FEEDBACK to GUIDE TEAM - TEAM COMMUNICATION IS BETTER! :D

XP (eXtreme Programming) ▸ Scrum focuses each day on the highest priority work item and focuses on doing tasks to

get this priority item DONE▸ Like XP, it requires a guide/coach/motivator rather than a planner/ delegator ▸ Unlike Scrum, XP is:

- does not have a backlog, but user stories- XP does not have much emphasis on analysis of a backlog- XP encourage practises to improve estimates ASAP- XP asks for a customer that is specification driven, not a Product Owner that Scrum has

Tracking and Monitoring

Why Track and Monitor? ▸ We want to know we can achieve our targets

- This is a meta-activity that should aide development- It isn’t a primary activity that shouldn’t hinder development

▸ We need to know that we can stay away from risks, or at least mitigate them as they come- Prevent surprises from happening- Monitor the fine-grain timing of certain events

▸ What can go wrong in projects?- Inadequate functionality of a product (validation)- Poor product quality (i.e., bad quality management)- Late delivery of product (i.e., bad project scheduling)- Exceeding budget (i.e., bad budgeting)

▸ How do we know what to check that problems will happen?- ( 1 ) Smell out the problem—collect data about what’s going on and use experience- ( 2 ) Devise a measurement of that problem- ( 3 ) Display the measurement—think of something to do

� / �37 44


- ( 4 ) Take corrective action to fix that problem- ( 5 ) If the problem does not go away, re-devise another measurement of the problem

Planning, Tracking and Monitoring ▸ Meta activities; no direct benefit but needed to help ensure project progress ▸ Helps ensure, but doesn’t guarantee

- that the project is delivered on time and in budget- meets a set quality standard- meets clients needs

▸ Plan - Know where we want to go - Activities

▪ Decompose the tasks

▪ Allocate resources to those tasks▪ Schedule and allocate milestones to them

▸ Track - Know where we are now - Activities

▪ Find out what is happing

▪ Collect data about current state of the project▸ Monitor

- Determine whether we are where we want to be

▪ Where are we now and is this where we want to go? (Plan vs. Track)

- Activities▪ Compare current status with target

status

▪ Control the project and ensure targets are met

▪ Contingency planning for risk

Tracking Techniques ▸ Set up checkpoints in advance

- Waterfall: Milestones and deliverables are good checkpoints

▪ Could based on a work product (milestone and deliverable)▪ Could also be Regular time intervals or particular events

- Scrum: Daily scrum meetings

� / �38 44

12

Tracking and Monitoring: Framework

Monitor the progress

gather project info.

compare progress vs targets

satisfied?

No

Yes

Take remedial

action

Publish revised

plan


- XP: 1-2 times per week at a standup▸ Collect data

- Relevant data that indicates the current project process - Relevant units should be used (i.e., NOT “Percent Complete”)

▸ Issues with Tracking- Honesty

▪ The data has to be honest and accurate: Can’t hear what you “want” to hear▪ Data shouldn’t judge their performance:▹ As a PM don’t tell a workmate that the tracking will judge them▹ i.e., don’t come to a conclusion that they promise things which they can’t deliver

- Issues

▪ Estimates can be wrong (make sure you adjust your estimates as you go along)

▪ Use good units of measurement (choose measurements that can’t expand and keep going—i.e., oh yeah we’ll give you another day etc.)

- Use burn-up/down charts to visualise progress to go (use VELOCITY of graph!)

▪ Burn down for iterations that are definitely completable at 0%

▪ Burn up for entire project schedule that has a dynamic 100% completeness

▪ Helps you see upcoming surprises and suppress them!

� - Remember, agile approach uses User Stories▪ This means that clients can keep adding user

stories as we go along

▪ Therefore 100% doesn’t make much sense to the y-axis scale because what defines “100%” is always changing and can increase

▪ Use # user stories for y-axis instead to make it adjustable (right)

20

Short vs. Long Time Intervals

Source: Alistair Cockburn, Crystal Clear, Addison-Wesley, 2004

25

Burn-down Charts


24

Burn-up Charts


Estimated Timeline

Actual Progress

� / �39 44

29

Do not Hesitate to Adjust Graphs!


▸ Methods for Tracking - XP progress tracking ▪ Let everyone see it—use a big board that’s visible for everyone

▪ Basically SSIL lab process▹ columns for status (backlog, working on, completed, approved by customer) and ▹ cards for user stories

- Traffic-Light Method

▪ Identify the key tasks to be completed▪ Break down each task into smaller subtasks

▪ Assess each of the subtasks in a RED, AMBER and GREEN status:▹ GREEN:

On target▹ AMBER:

Not on target, but can get back on track▹ RED:

Not on target and cannot get back on track without ease- Iceberg List ▪ Focus the most important tasks on the top

▪ The current iteration is “above” water, the future ones “below”▪ Sometimes, a bottom item may be “promoted” on top of the list…▹ Use color coding to help (i.e. RED, AMBER, GREEN)

Reporting ▸ Progress Reports

- Indicative of how much work was done by the personnel and time spent- Indicate how much work is yet to be done- Likelihood of failing to complete certain tasks- Estimated time of completion

▸ Risk Reports - Indicate the likelihood of meeting scheduled dates ▪ (are we definitely going to meet it)

- Traffic light method for risks to list▸ A report is therefore visible to:

- your team members- your superiors

▸ Keep an eye out for the truth (no one wants to see lies) and visibility of the graphs

� / �40 44

Current Iteration

Future Iterations


Team Management and Leadership Issues▸ Why do projects fail?

- Often it is NOT a technical failure ▸ Pressure to complete is causes people to:

- take shortcuts- poorer methods- gamble on new technologies that promise the world

▸ Pressure from management can also have a bad affect▸ Maslow’s Motivation Theory

- Physical Needs:

▪ basic needs; food, sleep, shelter- Safety Needs ▪ personal safety, secure

- Social Needs

▪ feel part of a group▪ communication

▪ provide common place of idea sharing- Esteem Needs ▪ feel valued

▪ public recognition- Self-Actualisation Needs ▪ personal development

▪ give people responsibility▪ allocate demanding, but not impossible, tasks

▸ Managers need to convey a message of hope and growth ▸ Issues with Motivation Theory:

- Motivation is usually based on personal aspects- It doesn’t give adequate consideration to an organisation culture

▸ Hezberg’s Motivation Theory - Motivational Factors

▪ Factors that motivate people▪ Achievement, recognition, responsibility

- Hygiene Factors

▪ Factors that detract motivation if not present▪ Bad salaries, poor supervision, strict working hours

▪ give me money and I’ll do well!

� / �41 44


▸ Personality Types - Myers-Briggs Psychological Personal Indicator (INTJ)▪ Ensuring you can understand another person’s behaviour can:▹ help job performance and teamwork performance▹ hiring and promoting process▹ forming good teams

▪ We aim to have a balance of MBTI personalities in a team- Introvert/Extroverts (E/I) — energy expenditure

▪ Introverts expend energy to their inner world (ideas and thoughts)

▪ Extroverts expend energy to their outer world (people and activities)- Sensing/Intuition (S/N) — how to gather information

▪ Sensors rely on data, trends and details (practicality)

▪ Intuition are imaginative, ingenious and have hunches (intuitions)- Thinking/Feeling (T/F) — how to make decisions

▪ Thinkers are objective and logical▪ Feelers are subjective and personal

- Judgement/Perception (J/P) — attitude on structure

▪ Judgers like closure and task completion; take deadlines seriouslywork now play later

▪ Preceptors are open and flexible; deadlines are a signal to startplay now work later

▸ Teamwork roles- Coordinators- Shapers (worriers)- Planters (generate ideas)- Monitor Evaluator- Resource Investigator- Team Worker- Implementer- Completer/Finisher (perfectionists)- Specialists (“techie”)

▸ A good mix of these roles help make a good team- Don’t want too many perfectionists- Don’t work with your friends (because you’re probably all similar and therefore there

isn’t a good mix)- We want a team where all of these roles are fulfilled

� / �42 44


▸ The Difficult People- Know-it-alls- Do-it-all-myself- Yes-men- Maybe-men- Nothing-men- No-men- Whiners

▸ Why do we want to build a good team?- Makes a team more effective- Helps improve project performance- A good team is more productive than the sum of individuals!

▸ May involve training and team-building activities▸ Help teams work together▸ How to build up a team?

- Forming—get to know each other- Storming—conflicts on leadership and methods- Norming—conflicts settled; team spirit emerges- Performing—team works on tasks- Adjourning—team disbands; all done

▸ Effective teams…- the output of the whole team is greater of the total output from each of the parts- team cohesion- good communicators

▪ transmission—say something

▪ reception—did you hear it ▪ understanding—do you understand what I said

▪ agreement—do you agree ▪ action—let’s go do that!

▪ bad communication problems:▹ assumptions are the mother of all fuck-ups ▹ noise; get to the point ▹ mismatch in talking; you’re saying A and I’m saying B ▹ dictation ▹ personal attacks ▹ not listening at all

- agreed goal tracking� / �43 44


- good feedback- common working framework- team spirit—mutual respect- open and free communication - plan for the work

▸ Team problems:- leadership; co-operation; participation; lack of trust; quality- function creep (want to do all the bells and whistles)

▸ Team management - make effective use of your people- the project succeeds on the people; that’s why management is important- opposing forces:▪ people need direction and control

▪ but at the same time people need freedom- ways to manage people:▪ directive autocrat: dictatorship

▪ permissive autocrat: decisions by leader; freedom for team to implement

▪ directive democrat; decisions made participation; leader has a final say▪ permissive democrat; all decisions made collaboratively

- good ways to manage:

▪ learn about what’s going out without micromanaging ▪ review processes and products, not people

▪ coordinate, don’t manipulate

▪ use knowledge, not power

▪ act as an enabler of people; not a disabler ▸ meetings

- time consuming!- be brief!- Be NEAT…▪ Need for the meeting

▪ Expectations of the outcome of the meeting

▪ Agenda ▪ Time

▸

� / �44 44

Documents

The Classical Software Lifecycle Project Practises and... · Software Project Practises And Management Alex Cummaudo SWE20003 7 Aug 2014 Quality Software Quality has diﬀerent stakeholder's