SENG411 L7 Notes

From Craig

Holding it all together - Project management

Conceptual Integrity:

• The most important aspect of any system.
• How is it achieved?
• Does it imply few people exercising creativity? (ie. the architects)
• How can we keep ideas realistic?
• How are details communicated?

Conceptual integrity is achieved through unity of design

• There is often a tradeoff between function and simplicity
• At the high level, this denotes architecture
• At lower levels, understanding and adherence to standards
• Assumes some level of control

To keep a vision, that vision should come from one or few people whom agree on that vision. However, as software becomes more complicated, more and more people are utilized in the effort to develop that software. Communication now becomes the most important part of holding to a common vision.

• Documentation
• Face-to-Face communication
• Scalability concerns

Documentation

• Not trivial
• Written specifications
• Tutorials

Effective Documentation

• Precision
• Enumeration
• Formal definitions
  • May be difficult to comprehend
  • Use prose to make easy to learn and teach
• Must elucidate "why"

Important Documentation

• Focus thought and crystalize discussions

Documents for a computer product

• Objectives
• Specifications
• Schedule
• Budget
• Organizational Chart
• Space Allocations
• Estimate, forecasts and prices.

Documents for a software project

• What: Objectives
• What: Specifications
• When: Schedule
• How Much: Budget
• Where: Space Allocation
• Who: Organizational chart
  • Conway's law: Organizations which design systems are constrained to produce systems which are copies of the communication structures of these organizations.

Why have formal documents?

• Writing down decisions is essential
• Documents will communication decisions to others
• Documentation provides a checklist

The task of a manager is to develop a plan and to realize it. Only a written plan is precise and communicable.

Project plan

The formal documents should be collected to form the Project Plan.

Project Plan discussion (http://pages.cpsc.ucalgary.ca/~schock/courses/f05/seng411/notes/project/ProjectPlan.html)

Project Management

The W⁵HH principle (Barry Boehm, 1996)

• Why is the system being developed? Does the business purpose justify the expenditure of people, time and money?
• What will be done?
• When will it be done?
• Who is responsible for a function?
• Where are they organizationally located?
• How much of the job will be done technically and managerially?
• How much of each resource is needed?

A group called the Airlie Council has developed a list of "critical software practices for performance based management". According to the council, these practices are "consistently used by, and considered critical by, highly successful software projects and organizations whose 'bottom line' performance is consistently much better than industry averages"

Critical practices include:

• metrics based project management
• empirical cost and schedule estimation
• earned value tracking
• formal risk management
• defect tracking against quality targets
• people aware management

Metrics based project management

Metrics vs statistics

• Metrics: no error term
• Statistics: error term

Implication of measurement

• How do you measure a software process?

What is it?

• Software process metrics are quantitative measures that enable software engineers to gain insight into the efficacy of the software process

Who does it?

• Metrics are analyzed and assessed by software managers. Metrics are often collected by developers

Why do it?

• Without measurements, judgement can be based only on subjective evaluation.
• To characterize in an effort to gain an understanding of processes, products, resources and environments and to establish baselines for comparisons with future assessments
• To evaluate and determin status with respect to plans
• To predict by gaining understanding of relationships between processes and products and to build models of these relationships
• To improve by identifying roadblocks, root causes, inefficiencies, and other opportunities for improving product quality and process performance.

Guidelines for using metrics:

• Use common sense and organizational sensitivity when interpreting metrics data
• Provide regular feedback to the individuals and teams who collect measures and metrics
• Don't use metrics to appraise individuals
• Work with practitioners and teams to set clear goals and metrics that will be used to achieve them.
• Never use metrics to threaten individuals or teams
• Metrics data that indicate a problem area should not be considered "negative". These data are merely an indicator for process improvement
• Don't obsess on a single metric to the exclusion of other important metrics.

Project Metrics

• Estimation (using metrics collected from past projects)
• Schedule (used to monitor progress)

Product Metrics

• Analysis metrics
  • Functionality delivered
  • System size
  • Specification quality
• Design metrics
  • Architectural metrics
  • Component-level metrics
  • Interface design metrics
  • Specialized design metrics (such as OO metrics)
    • Size
    • Complexity
    • Coupling
    • Sufficiency
    • Completeness
    • Cohesion
    • Primitiveness
    • Similarity
    • Volatility
• Source code metrics
  • Complexity metrics
  • Length metrics
• Testing metrics
  • Statement and branch coverage metrics
  • Defect related metrics
  • Testing effectiveness
  • In-process metrics (such as profilers)

Earned Value Analysis

Earned Value Analysis is a quanitative technique for assessing process as a software team moves through the tasks allocated in the project's schedule. It enables use to assess a "percent of completeness" of a project using quantitative analysis:

• Determine the budgeted cost of work scheduled (BCWS). For each task, the work (in time) of each task is planned.
• The sum of all tasks is computed
• Compute "percentage complete" by comparing sum of completed tasks against sum of all tasks.

Formal Risk Management

• Risk concerns future happenings.
• Can we change our actions today to create an opportunity for a better situation tomorrow?
• Risk involves change

Although risk has not been defined, there is general agreement about two characteristics:

• Uncertainty: it may or may not happen
• Loss: If risk becomes reality, unwanted consequences or loss will occur

The Risk plan: A systematic attempt to specify threats to the project plan (estimates, schedules, resources, etc). By identifying known and predictable risks, the project manager takes a first step towards avoiding them.

Two types of risks:

• Generic risks (a potential threat to all software projects)
• Project-specific risks

Seven principles to Risk Management

1. Maintain a global perspective: view software risks within the context of the system
2. Take a forward looking view: think about risks that may arise. Establish contingency plans to mitigate the risk
3. Encourage open communication: don't dismiss risks without contemplation
4. Integrate: consideration of risks must be part of the project plan
5. Emphasize a continuous process: Must be done throughout the lifetime of the project
6. Develop a shared vision: common views of the system (Conceptual integrity)
7. Encourage teamwork

Avoid having the "Risk Mangement Police" overwhelm the project with forms, reports, and other aspects of bureaucracy.

• XP and scrum have daily meetings which help to identify risk

Defect tracking against quality targets

What is quality software?

• It's not enough to say that quality is important.
• You have to explicitly define what is meant when you say "software quality".
• You have to explicitly create a set of activities that help ensure that every software engineering work product exhibits high quality.
• You have to explicitly perform quality control and assurance activities on every software project
• You have to explicitly use metrics to develop strategies for improving your software process and, as a consequence, the quality of the end product.

Software quality processes are defined by a SQA Plan (Software Quality Assurance).

The "Daily Build" Concept:

The entire application is compiled, linked and tested at the end of every day.

• Automated test scripts executed

People Oriented management techniques

Who are "the people"?

• Senior managers: Who define business issues
• Project managers: who plan, motivate, organize, and control the practitioners who do software work
• Preactitioners: Who deliver the technical skills that are necessary to engineer a product or application
• Customers: who specify the requirements
• End-users: who interact with the software once it's released into production

Four organizational "paradigms" for software teams:

• Closed paradigm: structures teams along a traditional hierarchy of authority
• Random paradigm: teams are structured loosely and that structure depends on individual initiative of team members. Useful when innovation is needed.
• Open Pardigm: Heavy communication and consensus-based decision making. Well suited to complex problem solving
• Synchronous paradigm: Based on natural compartmentalization of a problem. Little communication between team members.

Understand organizational culture:

• How do projects normally proceed in this organization?
• Are projects typically successful? What does successful mean?
• How to the software engineers view the projects?
• What confidence do software engineers have in organizational process, project schedules, CASE tools, measurements, managers, leadership and other project factors?

Understand each team member:

• What type of educational background does this person have?
• How much and what type of project experience does this person have?
• What generation does this person hail from?
• What personality traits does this person draw on?
• What are the strengths and weaknesses of this person, professionally and personally?

Match roles to people:

• Requirements engineer
• Lead Designer
• Coder
• Quality assurance engineer
• Customer liason
• Tools expert
• Other (roles project specific)

General people-oriented management guidelines:

• Gain visibility without micromanagement
• Review process and products, not people
• Coordinate, don't manipulate
• Use your knowledge, not your position of power
• Channel people, don't put obstacles in front of them
• Focus on people and people needs, not your authority as manager