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

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

A development process is a model that tells us how to build software.

• Defines the stages
• Defines the relationship between stages
• Defines the activities needed at each stage

The life cycle consists of the entire life of a software as a sequence of activities. It is therefore very dependent on the development process.

Software Project Management is heavily dependent on the development process because you cannot expect to manage something if you do not know how it works.

In the early days of software project management, there was no well defined development process. Programmer were given a project and they would then head off to code and test until they were done. This was obviously not a very efficient way of doing things and so eventually the Waterfall Process was heavily adopted. The idea for the Waterfall Process came from other engineering fields where such a process was the effective way of proceeding because the desired end product was well defined right from the beginning. However, with software projects, this model did not work well because software projects usually involve using new technologies and techniques and the requirements for the final end product are always changing.

Some problems that therefore would occur when using the waterfall method were:

• Late design breakage
  • Early success via paper designs and discussions in meetings but difficulty arising later during implementation and integration due to unforseen problems of complications.
  • Waterfall method forces band-aid solutions to problems since cannot go back to earlier stages of design. This results in a fragile and unmaintainable product.
• Late risk resolution
  • Too few tangible facts known at start when initial requirements are defined.
  • Risks become apparent later, and are expensive to mitigate.
• Requirement-driven functional decomposition
  • Attempting to define precise requirements and implement them exactly is not realistic.
  • Depends on requirements remaining constant.
• Adversarial stakeholder relationships
  • Difficulty in defining exact requirements leads to prolonged paper document exchanges at the beginning of the development process.
  • Leads to contract disputes over misinterpretation of requirements.
• Focus on documents and review meetings

Due to the weaknesses of the Waterfall Process, it has been replaced by the Iterative and Incremental Process. This process combines the waterfall process with an iterative process allowing each of the steps within the waterfall process to be re-visited many times throughout the development process.

Another model is the eXtreme Programming model. More about this can be read here.

—

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

Project Management is the discipline of organizing and managing resources (e.g. people) in such a way that the project is completed within defined scope, quality, time and cost constraints. A project is a temporary and one-time endeavor undertaken to create a unique product or service, which brings about beneficial change or added value. [3]

The goal of software project management is to understand, plan, measure and control the project such that it is delivered on time and on budget. This involves gathering requirements, managing risk, monitoring and controlling progress, and following a software development process.

Software project management requires trained and experienced Software Engineers in order to increase the likelihood of project success because software development for large projects is extremely complex and following strict engineering principles will help reduce the risks associated with the project.

Software project management is extremely important for the following reasons:

• Software development is highly unpredictable: [as of 2007?] only about 10% of projects are delivered within initial budget and on schedule. [1]
• Management has a greater effect on the success or failure of a project than technology advances. [1]
• Too often there is too much scrap and rework. The entire process is very immature, not enough reuse. [1]

According to the 10th edition of the annual CHAOS report from The Standish Group, only 34% of projects are completed successfully. While this actually represents a huge improvement, there is obviously still room for more! Why have things started to get better?

Standish Chairman Jim Johnson says, “The primary reason is the projects have gotten a lot smaller. Doing projects with iterative processing as opposed to the waterfall method, which called for all project requirements to be defined up front, is a major step forward. [4]

Project failure in itself is not the only reason why software management is so important. When a project fails, not only is a product not delivered, but all the money invested in the product is also lost. Without proper software management, even completed projects will be delivered late and over budget. Take a look at some of these examples of expensive software failures.

The 2004 CHAOS report, entitled “CHAOS Chronicles,” found total U.S. project waste to be $55 billion, made up of $38 billion in lost dollar value and $17 billion in cost overruns. Total project spending was found to be $255 billion in the 2004 report.

In 1994, The Standish Group estimated U.S. IT projects wasted $140 billion—$80 billion of that from failed projects—out of a total of $250 billion in project spending. [4]

If the risk of failure and loss of money is not enough to convince you of the importance of proper software management, consider that some software will also put the lives of people at risk. Go read Software Horror Stories or History’s Worst Software Bugs to see some examples…

failures are universally unprejudiced: they happen in every country; to large companies and small; in commercial, nonprofit, and governmental organizations; and without regard to status or reputation. [5]

So why does software fail anyways? Here is the list from the IEEE Spectrum [5]:

• Unrealistic or unarticulated project goals
• Inaccurate estimates of needed resources
• Badly defined system requirements
• Poor reporting of the project’s status
• Unmanaged risks
• Poor communication among customers, developers, and users
• Use of immature technology
• Inability to handle the project’s complexity
• Sloppy development practices
• Poor project management
• Stakeholder politics
• Commercial pressures

Software project failures have a lot in common with airplane crashes. Just as pilots never intend to crash, software developers don’t aim to fail. When a commercial plane crashes, investigators look at many factors, such as the weather, maintenance records, the pilot’s disposition and training, and cultural factors within the airline. Similarly, we need to look at the business environment, technical management, project management, and organizational culture to get to the roots of software failures.

THE PILOT’S ACTIONS JUST BEFORE a plane crashes are always of great interest to investigators. That’s because the pilot is the ultimate decision-maker, responsible for the safe operation of the craft. Similarly, project managers play a crucial role in software projects and can be a major source of errors that lead to failure.

Bad decisions by project managers are probably the single greatest cause of software failures today. Poor technical management, by contrast, can lead to technical errors, but those can generally be isolated and fixed. However, a bad project management decision—such as hiring too few programmers or picking the wrong type of contract—can wreak havoc.

Project management decisions are often tricky precisely because they involve tradeoffs based on fuzzy or incomplete knowledge. Estimating how much an IT project will cost and how long it will take is as much art as science. The larger or more novel the project, the less accurate the estimates. It’s a running joke in the industry that IT project estimates are at best within 25 percent of their true value 75 percent of the time.

Poor project management takes many other forms, including bad communication, which creates an inhospitable atmosphere that increases turnover; not investing in staff training; and not reviewing the project’s progress at regular intervals. Any of these can help derail a software project. [5]

Another problem which distinguishes software engineering from other engineering fields is the fact that software is not concrete. There is a common misconception that software can be easily changed to do anything no matter which stage the project is currently at. If construction on a building or bridge is nearly complete, people understand that it is too late to make significant changes to the architecture or design. However with software, clients tend to have the impression that making changes are always easy even though the end result could be the equivalent to tearing down a nearly completed building!

A common misconception is that developing software means writing code, which is definitely not the case. Code writing itself only counts for about 40% of software development. There are many other important steps such as requirements, configuration, deployment and maintenance. [1]

The main goal of software project management is to try and reduce the risks involved with a project such that the project can then finish on budget and on time with all of the features desired by the clients..

Project management helps us achieve the following [1]:

• Estimate the budget needed to complete the project before it starts and to monitor the progress so that at any given time we know how much a project has cost and how much more it will cost.
• Estimate the time needed to complete at project before it starts and to monitor the progress so that at any given time we know how much time is left before completion.
• Estimate which features can be developed in the given time and cost frame.
• Monitors the project progress and so we know which features have been completed and which ones will be completed before the end of the project.
• Software delivered must provide all the features specified in the requirements (feature complete). Project management therefore helps project managers re-negotiate features and requirements.

Software users are among the worst treated customer in engineering. It is taken for granted without much complaint that software has bugs, crashes from time to time, doesn’t work occasionally and is too complicated to install and use. Quality must be a given part of the scope; the completed features must be of high quality. [1]

Since project management is so important, we need to be able to rank organizations in terms of their software capability and maturity. We use the Capability and Maturity Model (CMM) to achieve this.

CMM ranks the software development process of a firm by using 5 levels of maturity

Level 1 - Initial

At maturity level 1, processes are usually ad hoc, and the organization usually does not provide a stable environment. Success in these organizations depends on the competence and heroics of the people in the organization, and not on the use of proven processes. In spite of this ad hoc, chaotic environment, maturity level 1 organizations often produce products and services that work; however, they frequently exceed the budget and schedule of their projects

Maturity level 1 organizations are characterized by a tendency to over commit, abandon processes in the time of crisis, and not be able to repeat their past successes again.Level 1 software project success depends on having high quality people.

Level 2 - Repeatable [Managed]

At maturity level 2, software development successes are repeatable. The processes may not repeat for all the projects in the organization. The organization may use some basic project management to track cost and schedule.

Process discipline helps ensure that existing practices are retained during times of stress. When these practices are in place, projects are performed and managed according to their documented plans.

Project status and the delivery of services are visible to management at defined points (for example, at major milestones and at the completion of major tasks).

Basic project management processes are established to track cost, schedule, and functionality. The minimum process discipline is in place to repeat earlier successes on projects with similar applications and scope. There is still a significant risk of exceeding cost and time estimates.

Level 3 - Defined

The organization’s set of standard processes, which are the basis for level 3, are established and improved over time. These standard processes are used to establish consistency across the organization. Projects establish their defined processes by the organization’s set of standard processes according to tailoring guidelines.

The organization’s management establishes process objectives based on the organization’s set of standard processes and ensures that these objectives are appropriately addressed.

A critical distinction between level 2 and level 3 is the scope of standards, process descriptions, and procedures. At level 2, the standards, process descriptions, and procedures may be quite different in each specific instance of the process (for example, on a particular project). At level 3, the standards, process descriptions, and procedures for a project are tailored from the organization’s set of standard processes to suit a particular project or organizational unit.

Effective project management system is implemented with the help of good project management software.

Level 4 - Quantitatively Managed

Using precise measurements, management can effectively control the software development effort. In particular, management can identify ways to adjust and adapt the process to particular projects without measurable losses of quality or deviations from specifications. Organizations at this level set quantitative quality goals for both software process and software maintenance. Subprocesses are selected that significantly contribute to overall process performance. These selected subprocesses are controlled using statistical and other quantitative techniques. A critical distinction between maturity level 3 and maturity level 4 is the predictability of process performance. At maturity level 4, the performance of processes is controlled using statistical and other quantitative techniques, and is quantitatively predictable. At maturity level 3, processes are only qualitatively predictable.

Level 5 - Optimizing

Maturity level 5 focuses on continually improving process performance through both incremental and innovative technological improvements. Quantitative process-improvement objectives for the organization are established, continually revised to reflect changing business objectives, and used as criteria in managing process improvement. The effects of deployed process improvements are measured and evaluated against the quantitative process-improvement objectives. Both the defined processes and the organization’s set of standard processes are targets of measurable improvement activities.

Process improvements to address common causes of process variation and measurably improve the organization’s processes are identified, evaluated, and deployed.

Optimizing processes that are nimble, adaptable and innovative depends on the participation of an empowered workforce aligned with the business values and objectives of the organization. The organization’s ability to rapidly respond to changes and opportunities is enhanced by finding ways to accelerate and share learning.

A critical distinction between maturity level 4 and maturity level 5 is the type of process variation addressed. At maturity level 4, processes are concerned with addressing special causes of process variation and providing statistical predictability of the results. Though processes may produce predictable results, the results may be insufficient to achieve the established objectives. At maturity level 5, processes are concerned with addressing common causes of process variation and changing the process (that is, shifting the mean of the process performance) to improve process performance (while maintaining statistical probability) to achieve the established quantitative process-improvement objectives.[2]

Project Performance Expectation

[1]

Capability Maturity Model Key Process Areas

Initial

• Ad hoc

Repeatable

• Software Configuration Management
• Software Quality Assurance
• Software Subcontract Management
• Software Project Tracking and Oversight
• Software Project Planning
• Requirements Management

Defined

• Peer Reviews
• Intergroup Coordination
• Software Product Engineering
• Integrated Software Management
• Training Program
• Organization Process Definition
• Organization Process Focus

Managed

• Software Quality Management
• Quantitative Process Management

Optimizing

• Process Change Management
• Technology Change Management
• Defect Prevention

Key Process Areas Across Categories

[1]

—

[1] Prof. Shervin Shirmohammadi, University of Ottawa SEG4100 Course Notes, Lecture 1
[2] Wikipedia, Capability Maturtiy Model
[3] Wikipedia, Project Management
[4] Softwaremag.com, Standish: Project Success Rates Improved Over 10 Years
[5] Robert N. Charette, IEEE Spectrum, Why Software Fails