Software Engineer Training Knowledge, tools, and methods for defining requirements and performing design, implementation, testing and maintenance

NEW YORK – People for the Ethical Treatment of Software (PETS) announced today that more software companies have been added to the groups “watch list” of companies that regularly practice software testing.

“There is no need for software to be mistreated in this way so that companies like these can market new products,” said Ken Granola, a spokesman for PETS. “Alternative methods of testing these products are available.”

According to PETS, these companies force software to undergo lengthy and arduous test – often without rest – for hours or days at a time. Employees are assigned to “break” the software by any means necessary and inside sources report that they often joke about “torturing” the software.

“It’s no joke,” Granola said. “Innocent programs, from the day they are compiled, are cooped up in tiny rooms and ‘crashed’ for hours on end. They spend their whole lives on dirty, ill-maintained computers, and they are unceremoniously deleted when they’re not needed anymore.”

Granola said that the software is kept in unsanitary conditions and is infested with bugs.

“We know alternatives to this horror exist,” he said, citing industry giant Microsoft Corp. as a company that has become successful without resorting to software testing.

Thank you John McCormick for this one!

A software engineer, a hardware engineer and a department manager were on their way to a meeting in Switzerland. They were driving down a steep mountain road when suddenly the brakes on their car failed. The car careened almost out of control down the road, bouncing off the crash barriers, until it miraculously ground to a halt scraping along the mountainside.

The car’s occupants, shaken but unhurt, now had a problem: they were stuck halfway down a mountain in a car with no brakes. What were they to do?

“I know,” said the department manager, “Let’s have a meeting, propose a Vision, formulate a Mission Statement, define some Goals and by a process of Continuous Improvement find a solution to the Critical Problems, and we can be on our way.”

“No, no,” said the hardware engineer, “That will take far too long, and besides, that method has never worked before. I’ve got my Swiss Army knife with me, and in no time at all I can strip down the car’s braking system, isolate the fault, fix it and we can be on our way.”

Well,” said the software engineer, “Before we do anything, I think we should push the car back up the road and see if it happens again.”

Thank you John McCormick for this one!

Software Project Estimation [1]

• You can’t manage something which you can’t measure
• We need some sort of measurement for:
  • size of the project
  • effort and cost
• Estimating software projects is notoriously poor.
• If performance doesn’t meet estimates then either:
  • the performance was poor; or
  • the estimate was poor

Impact on Development Process [1]

• One of the key factors in software project management
• If “software managers and engineers are trained in and apply software estimating and planning procedures”, then you are one step closer to CMM level 2 (repeatable).

Lines of Code [1]

• The most commonly used size indicator, but obviously not the best one!
• Issues:
  • How can lines of code be defined?
  • How can the total lines of code be known before coding?
  • How interpret lines of code? Is 250 more productive than 200?
  • What about different programming languages which have a different syntax?

Lines of Code Calculation [1]

• Prerequisite for line of code calculations is the work breakdown structure
• Line = statement
• Line = data definition
• Line != comments
• Line != debug code
• Line != test cases
• For different languages, convert all to assembly.

Beta Distribution Measurement [1]

• Ask developers for the following line of code values:
• Optimistic (0)
• Pessimistic (P)
• Realistic (R)

LOC = (O+P+4*R)/6

• ex: R=250, O=200, P=400
  • LOC = 266

The Blitz [1]

• Based on historical observation of previous projects.

LOC = Processes * prgs/processes * avg. prg size

• Process = class, db table, …
• Ex: 20 classes, 1 program/class, 50 java lines of code/program
  • LOC = 20*1*50 = 1000

Wideband Delphi [1]

• Based on the experience of developers

1. Gather experts
2. Conduct group discussion
3. Gather estimates
4. Distribute estimates
5. Repeat until consensus is reached

• Pros:
  • Takes advantage of experience
  • educates developers about the software
  • reinforces team concept

Function Points [1]

• Uses the functionality of the software as a measure of its complexity.
• Analogy: For a given house, we can say how many square meters it has (lines of code) or we can say how many bedrooms and bathrooms it has (function points).
• A measure of the functionality of a given software.
• Works best for traditional applications; not very suitable for algorithmically intensive applications. (ex: real-time and embedded applications)

Weighting Factor [1]

• There are tables that provide the project manager with a weighting factor for each category.
• Input can be:
  • Simple (weighting factor=4)
  • Average (weighting factor=5)
  • Complex (weighting factor=7)
• Ex: 1 to 5 data items referenced from 1 file is considered a simple function. Same action from 5 files is considered average.
• Sum of all weighted categories is the raw function points.

Environmental Factors [1]

• Data Communications
• Distributed Computing
• Performance Requirements
• Constrained Configuration
• Transaction Rate
• Re-usability
• Ease of Operation
• And much more…

• For a given project, each factor is rated from 0 (no effect) to 5 (highly affects).
• Sum of all gives the environmental influence factor (N)

Adjustments

• Complexity Adjustment Factor (CAF)
  • Assumes a +-35% inaccuracy in early estimates; therefore:

CAF = 0.65 + 0.01*N

• Adjusted Function Points (AFP)

AFP = CAF * rawFunctionPoints

• Convert to lines of code using tables

Differences with Function Point [1]

• Also includes number of algorithms
  • weighting factor for an algorithm is 3
• Uses average weighting factors instead of simple, average, and complex values.
• Uses 2 environmental factors: logical complexity and data complexity.
• CAF is calculated using a table.

Object Points

• Uses a similar process to function points and feature points.
• Suits object-oriented software.
• Uses different weighting factors and tables.

—

[1] Prof. Shervin Shirmohammadi, University of Ottawa SEG4100 Course Notes, Lecture 5

Work Breakdown Structure [1]

• A hierarchical list of work activities needed to complete the project; a description of the work to be performed broken down to its key components, down to the lowest level.
• Divide and conquer level
• Work breakdown structure identifies activities at a level useful for selecting the team with the proper skills.
• Based on staff number and estimates for the work breakdown structure, schedule cost and duration can be estimated.

Work Breakdown Structure Architecture [1]

• The work breakdown structure must cover all activities
• it is crucial to capture all disciplines or stages (requirements, design, implementation, testing…)
• Project manager must ensure everything is covered

Work Breakdown Structure Ganularity [1]

• Avoid too much detail and granularity.
• Don’t plan in more detail than you can manage
• Project manager has to train and trust the engineering team for those.
• Stop at a level where there is sufficient information for the people who will work on the activity.
• Obviously, don’t be too general either!

Milestones [1]

• A milestone is a significant event
• Usually associated with an interim deliverable
• For IIP, there can be a milestone at the end of each iteration.
• For eXtreme Programming (XP), there is typically a milestone every 1 to 3 weeks.
• Important to get the numbers right:
  • Too few: big-bang effect, progress will be hard to track
  • Too many: slows down project
• It is achieved as the result of the completion of a number of activities.

Work Packages [1]

• Lowest identifiable activities to be completed
• Contains:
  • Description of work
  • Staffing requirement (who, how many)
  • Name(s) of personnel responsible for completion
  • Schedule
  • Budget ($, hours, …)
  • Acceptance criteria (quality)
• Used mostly for large groups, or smaller groups of people who haven’t worked with each other before; rarely used in smaller organizations.

Activities and Tasks [1]

• Activity: the smallest component of the work breakdown structure, usually contains many tasks.
• Task: the lowest level of effort, typically achievable by one individual.
• Initially, an educared guess from past experience can be sufficient for the size of an activity. As requirements evolve, this size is estimated better.
• We cannot have all the details needed for a project plan at the beginning!
• It might be necessary later to break down larger activities
• IEEE 1074 provides a set of 65 activities carried out by software project activities (not all of which are needed for all projects, but still a good guidelines)

3 Level Work Breakdown Structure [1]

One possible way to tackle the work breakdown structure:

• Level 1: workflows
  • Management, environment, requirements, design, …
• Level 2: phases
  • Inception, elaboration, construction, transition
• Level 3: activities
  • Lowest level that may be a work package or lead to a number of work packages

Creating the Work Breakdown Structure [1]

• Go through existing documents
  • requirements
  • design documents
  • customer conversations
• Synchronize the work breakdown structure with the process framework: keep in mind the life cycle when doing the work breakdown structure.
• Project manager: sanity check the work breakdown structure:
  • everything is covered
  • granularity is appropriate

—

[1] Prof. Shervin Shirmohammadi, University of Ottawa SEG4100 Course Notes, Lecture 4

Project Phases [1]

• Inception: Establish the project’s scope and boundary, find the critical use cases, exhibit a candidate architecture, estimate the overall cost and schedule for the whole project, with details for the elaboration phase, and estimate risks.
• Elaboration: Define and validate the architecture, baseline a detailed plan for the construction phase
• Construction: Achieve useful versions (alpha, beta…), achieve adequate quality.
• Transition: Achieve final product baseline, achieve stakeholder concurrence of completeness

Project Disciplines [1]

Process Disciplines

• Business Modeling
• Requirements
• Analysis & Design
• Implementation
• Testing
• Deployment

Support Disciplines

• Configuration Management
• Change Management
• Project Management
• Environment

Architecture [1]

• The set of views, for the architecturally-significant components, of requirements, analysis, design, implementation, testing, and deployment.
• Similar to a blue print

Requirements Gathering [1]

• Gather all stakeholders
  • an individual or group of individuals with a common interest in the software
  • there may be conflicting interests among stakeholders!
  • can be customers, consumers, owners, partners, funders,subcontractors, internals, society, etc…
• Achieve sufficient requirements
  • Avoid designs details
  • Avoid implementation details
  • Cover only the functions that the software must provide
  • At this stage, don’t be concerned with how the functions are provided
• Use notations to capture requirements (ex: UML)
  • Don’t just talk about the software, but capture things on paper

<insert info on UML, show user case diagrams>

Use Case Scenarios [1]

• One or more user scenarios are written down for each use case
  • a lot of ambiguities are resolved at this stage
  • still lots of details remain and are avoided

Ex: Use case: show profile

1. START: user activates the show profile feature
2. software asks user to specify profile parameters
3. software retrieves parameters for database and displays them to the user
4. FINISH: user cancels the feature

Non-Functional Requirements [1]

• Captured as part of requirements gathering stage

Ex: (the software should answer queries within 3 seconds)

Requirements Document [1]

• Includes functional and non-functional requirements
• Must be signed off by stakeholders

Goal, Objective and Scope [1]

• Goal: must be defined crisply and clearly
• Objectives: for a specific target
  • SMART: Specific, Measurable, Achievable, Realistic, Time-Bound.
• Scope: boundaries of the project: does and does not list
  • not to be confused with features or requirements

Project Charter [1]

• A document that formally recognizes the existence of a project
• Provides the project manager with the authority to apply organizational resources to the project: what the project manager can and cannot do.
• Defines the project goal, scope, and objectives
• Details the level of quality to be expected
• Validates the business justification
• highlights the risk
• It is the contact: if anything needs resolution, this should specify it
• when in doubt, read the charter
• Also specifies the following:
  • what to do if there is a conflict
  • management reconciliation
  • scope change management
  • knowledge transfer
  • training approach
  • anything else…

Sample Charters:

• Eclipse Project Charter
• Treasury Board of Canada Secreteriat
• Projectability Charter

—[1] Prof. Shervin Shirmohammadi, University of Ottawa SEG4100 Course Notes, Lecture 3