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

Specific design principles underlie the design and implementation of mechanisms for supporting policies. These principles build on the ideas of simplicity and restriction. Simplicity reduces the potential for inconsistencies within a policy or set of policies. Restriction minimizes the power of an entity. The entity can access only information it needs. [1]

Saltzer and Schroeder [2] describe eight principles on the ideas of simplicity and restriction:

1. Principle of least privilege - states that a subject should be given only those privileges that it needs in order to complete a task.
   • If a subject does not need an access right, the subject should not have it.
   • The function of the subject should control the assignment of rights
     • If specific actions require that a subjects access right be augmented, those extra rights should be relinquished immediately on completion of the action.
   • Requires that processes be confined to as small a protection domain as possible.
2. Privilege of fail-safe defaults - states that, unless a subject is given explicit access to an object, it should be denied access to that object.
   • Requires that the default access to an object be none.
   • If a subject is unable to complete its action or task, it should undo those changes it made in the security state of the system before it terminates so that even if the program fails the system is still safe.
3. Principle of economy of mechanism - states that security mechanisms should be as simple as possible.
   • If a design and implementation are simple, fewer possibilities exist for errors.
   • The checking and testing process is less complex, because fewer components and cases need to be tested.
4. Principle of complete mediation - requires that all accesses to objects be checked to ensure that they are allowed.
   • If the system checks that a user has permission to access a file and then permission is granted to access the resource, the next time the user requests that same file, the system should again check if the subject is still allowed to access the resource. Do not cache the results of the first check!
5. Principle of open design - states that the security of mechanism should not depend on the secrecy of its design or implementation.
   • It should be assumed that attackers know or can find out all the design details of the system through some means and therefore secrecy of the design should not be part of the security.
6. Principle of separation of privilege - states that a system should not grant permission based on a single condition.
7. Principle of least common mechanism - states that mechanisms used to access resources should not be shared.
   • Sharing resources  provides a channel along which information can be transmitted, so this should be minimized.
8. Principle of psychological acceptability- states that security mechanisms should not make the resource more difficult to access than if the security were not present.
   • Configuring and executing a program should be as easy and as intuitive as possible and any output should be clear, direct and useful.
   • If security related software is too complicated to configure, administrators may unintentionally setup the software in a nonsecure manner.

—

[1] Matt Bishop, Introduction to Computer Security, Addison-Wesley, 2005

[2] J. Saltzer and M. Schroeder, The Protection of Information in Computer Systems, Proceeding of the IEEE 63 (9), pp. 1278-1308 (Sep. 1975)