Software Engineering Course

Corsica - USA

Corsica - USA

IndoTech Solutions, Inc., LLC, 711 S. Carson, Suite 4, Carson City, NV 89701, USA

Tel 775-881-3436 [email protected]

Software Engineering

University of Corsica

March-April 2002 by

Robert L. Straitt Organizational Performance Architect

8362 Tamarack Village 119-145, Woodbury, MN 551125, USA


Corsica - USA

04-05/2002 IndoTech Solutions, Inc., LLC, 711 S. Carson, Suite 4, Carson City, NV 89701, USA


1

Introduction

Overview

This course is designed to give students a basic understanding of the

management demands that a software project creates within an organization,

from its conception to retirement. It provides for hands on experience to the

students through the development and implementation of a mini software

project by the students. The students will be exposed to some of the pressures

of the software industry work environment by having to cope with formal

planning documents, estimating, project reviews and delivery of the product

on a very tight schedule. The course emphasizes the formal principles of

software engineering over the technical activities of programming to give the

students a better understanding of how successful software projects are

managed and implemented.

Corsica - USA



2

Lesson #1 Introduction to Software Engineering

Corsica - USA



3

Lesson #1 Introduction

Topics for this Class

•Distinction between Programming and Software engineering

•Knowledge Requirements for Software Engineering

•A history of Software Engineering

•Introduction of the Life Cycle Concept

•Present the Class Project

Corsica - USA



4


What is the difference between

Software Engineering and

Application Development (Programming)?

Corsica - USA



5


Engineering

Programming

Vs.

Corsica - USA



6


Engineering

•Understanding the problem

– Business Goals

– Operational Issues

– Business Environment

•Understanding the Technology

– Tools Available

– Methodologies

– Impacts of Choices

•Architecting a solutions

– Technical approaches

– Cultural change management

– Business and Financial Drivers

Programming

• Understanding the requirements

– Product purpose

– Functional Usage

– End result

• Understanding the Software

– Fluent in Language Syntax

– Command Structure

– Programming Techniques

• Building the Solution

– Code only functions specified

– Verify functional value

– Fix and maintain

Programming vs. Engineering

Corsica - USA



7


Software Engineering

• The science of understanding and translating real world

challenges into detailed technical issues, product

descriptions, and implementation strategies.

• It begins with the knowledge and understanding of the

processes involved in gathering the user needs (not just

desires), assessing the operational environment, and

defining the cultural impacts that will result from the

engineered change.

Corsica - USA



8


Software Engineering (cont.)

• It Transitions through the application of technical processes to

implement the engineered solutions and modify work planned to

adapt to ongoing changes in the operational environment.

• It ends when a product has been brought out of the production

environment and will no longer be used.

Corsica - USA



9


Software Engineering Processes

Broad-basedTQM

Philosophy

ProceduresTrainingPeople

Methods

CaseTools

- Measurement/metrics- Analysis- Design -- data design -- architectural design -- procedural design- Coding- Testing- Re-engineering (Maintenance) -- restructuring -- reverse engineering -- forward engineering- Reuse

- Project management tools- System support tools- Methods support tools- Coding support tools- Architecture tools- Reuse repository

- Project plan and process framework documented and followed- Measurement program- Reuse program- Software quality assurance (SQA)- Change control (configuration management)- Size/cost/schedule est imation and tracking- Requirements established and controlled- Peer inspections of process and product- Activities coordinated by functional group- Project-specific training program- Dedicated process improvement group

Guidelines for Successful Acquisition and Management of Software Intensive Systems, 1996

Corsica - USA



10


Software Engineering Processes

• Iteration between formal and analysis and design

• Heavy use of earlier designs

• Trade-offs between alternatives

• Handbooks and manuals

• A pragmatic approach to cost-effectiveness, and

• Attention to economic concerns.

[MOSEMANN92]

Corsica - USA



11


History of Software Engineering

• Software development began as an ad-hoc effort

performed by software artist.

• Software development transitions into a an art from

accomplished by skilled artisans.

• Software development reaches a level of complexity that

requires the emergence of a formal engineering

discipline.

Corsica - USA



12


History of Software Engineering (cont.)

25

Software Engineering is Different ThanSoftware-as-Art or -Craft

ART CRAFT ENGINEERING

Fido


Corsica - USA



13


History of Software Engineering (cont.)

• 1950’s Software development was like the early airplane development, trial and error with more error then success.

• 1960’s Software development was like an art form with each project being built uniquely and no two software products even similar.

• 1970’s Software products became larger and more complex early engineering concepts tried.

• 1980’s Software products were so large and complex that engineering methods became a necessity.

• 1990’s Software technology had advanced beyond the engineering methods in use and new formal processes were required to complete software projects.

Corsica - USA



14


Product Life Cycles

• The Product Life Cycle is the natural ordered sequence of activities

performed to develop and maintain a product.

• The Product life cycle begins with a customer recognizing a

business needs and progresses through development, fielding,

operation, and eventual retirement of the product.


Corsica - USA



15


Formulate

Need

Define

Concept

Demonstrate

& Validate

Requirements

Analysis

System

Architecture

Detailed

Design

Build

System

Migrate

System

Operated

System

Maintain

System

Phase 0 Phase I Phase II Phase III Phase IV

Decision

Point 1

Decision

Point 2

Decision

Point 3

Identify Needs

Gather User Requirements

Project Activation Funding Point

Validate Concept

Refine Requirements & Complete Project Documentation

Develop Funding Documentation

FUNDING POINT: Approval for System Development

Preliminary Design (high level)

Detailed Design

FUNDING POINT: Design Review and Approval to Build

Build or Acquire System

Installation and System Migration

CHECK POINT: Physical Audit


CHECK POINT: Post Project Review

System Maintenance


Corsica - USA



16


Class Project Overview

• The class project will help introduce you to the realities faced by software engineers

and developers in the commercial world.

• The project will help to demonstrate the differences between engineering and

development. It will high-light the challenges and obstacles faced by developers

when asked to perform engineering tasks.

• The project will also show the technical and schedule challenges faced by

engineering teams as the design a software application.


Corsica - USA



17


Class Project Content

• The project will involve the design and implementation of a simple application using

one of the MS-Office Suite applications. (Excel)

• Focus will be on Engineering activities (Requirements, Design, Architecture,

Quality, Configuration, and Documentation)

• We will build at least one Excel application to demonstrate the processes of software

engineering discussed in class.


Corsica - USA



18


Class Project

Create an activity tracking application in Excel

• Gather the Need for this from customer (instructor)

• You must define the requirements

• You must document the plan to complete the project

• You must document the design

• You must estimate how long it will take to do each task in the design

• You must have a project review with the class to discuss the plan and design

• Project must be designed in individual sheets that will be built by separate people.

Corsica - USA



19

Lesson #2

Project Organization

Corsica - USA



20

Lesson #2 Project Organization

Organizational

Issues

Engineering

Issues

People

Issues

GOAL

Through an integrated management process address the key

elements of a software systems engineering environment.

Corsica - USA



21


Organizational

Issues

Engineering

Issues

People

Issues

Corsica - USA



22


Engineering Issues

•Structured development Environment

•Standard engineering methods

•Formal processes and procedures

•Reusable engineering and development tools

•Common (tailored) core components.

Corsica - USA



23


Organizational

Issues

Engineering

Issues

People

Issues

Corsica - USA



24


Organizational Issues

• Management that sets Business Goals

• Process Based management methods

• Open Communications environment

• Provide the Right Tools at the Right Time

• Management Incentives that match business goals

• Ongoing Training that is up to date

Corsica - USA



25


Organizational

Issues

Engineering

Issues

People

Issues

Corsica - USA



26


People Issues

• Defined roles, responsibilities, and accountability.

• Open Communications with all levels

• Professional domain structure/ladder

• Individual improvement goals

• Recognition of disciplined and creative anticipation.

Corsica - USA



27


ow do you turn

this…

Into this?

Organizational Process Management

Corsica - USA



28



Process based management methods allow for software

organizations to benefit from the efficiencies of management

control ……..

……while maintaining the advantages of the dynamic and

diversified expertise base that they have fought to establish.

Corsica - USA



29



Traditional software organizations are organized and

managed through the use of a hierarchical management

structure that operates much like a bureaucracy.

The emphasis usually being on how do I not upset the status

quo, rather then how do I get things done.

The result inter-group oriented initiatives are usually quashed

before they can prove themselves and highly skilled experts

are silenced by inexperienced bureaucrats.

Corsica - USA



30


Requirements

Design

Acquisition

Testing

Quality

Assurance

Audit

Business

Support

Operations Users

Maintenance Production

Business

Goals

User

Needs Methods

Tools

Technology

Internal

Build

Vendors

Outsource

Admin Contracting

Legal

Seamless

Flow of

Information

Software System Engineering Environment

Corsica - USA



31


S/W

Engineers

Quality

Engineers

S/W

Developers

Project

Control

Projec Manager

Group

Manager

S/W

Engineers

Quality

Engineers

S/W

Developers

Project

Control

Project Manager

Group

Manager

Director

VP

Software Development

Recruiters

Department

Manager

Human Resources

Manager

Accountants

Finance

Manager

Accountants

Purchasing

Manager

Director

Operations

VP

Operations

CIO

Traditional Organizational Structure

Corsica - USA



32


S/W

Engineers

Quality

Engineers

S/W

Developers

Project

Control

Projec Manager

Group

Manager

S/W

Engineers

Quality

Engineers

S/W

Developers

Project

Control

Project Manager

Group

Manager

Director

VP


Recruiters

Department

Manager

Human Resources

Manager

Accountants

Finance

Manager

Buyers

Purchasing

Manager

Director

Operations

VP

Operations

CIO

Traditional Communications Flow

Typical

Communications

Path

Corsica - USA



33


Traditional Communications Flow

Safe? or Inefficient?

What facilitators for effective communication flow exists in

this organization?

What barriers to effective communication flow exists in

this organization?

Can Communication be effective in this organization?

Corsica - USA



34


Quality

Manager

Process

Manager

S/W

Engineers

S/W

Developers

Projec Manager

Group

Manager

S/W

Engineers

S/W

Developers

Project Manager

Group

Manager

Director

VP


Configuration

Manager

Project Control

Manager

Group

Manager

Director

Support Engineering

Recruiters

Department

Manager

Human Resources

Manager

Accountants

Finance

Manager

Buyers

Purchasing

Manager

Director

Operations

VP

Operations

CIO


Corsica - USA



35


Process Management Communications Flow

Anarchy? or Effective?

What facilitators for effective communication flow exists in

this organization?

What barriers to effective communication flow exists in

this organization?

Can Communication be effective in this organization?

Corsica - USA



36


Integrated Product Teams

(IPTs)

Integrated product teams are project level teams that are

staffed by software development experts and by individuals

from other organizations within company with the authority

to complete the tasks assigned.

Integrated product teams have a manager that is directly

responsible to upper management for the performance of the

project and who is the single point of contact for the

customer for total product quality.

Corsica - USA



37


Integrated Product Teams

(IPTs)

Customer

Organization

Integrated

Product

Team Customer

Representative

Project

Manager

Management

Corsica - USA



38


To IPT or Not To IPT?

A Bunch of People trying to do

something!

Working harder and acting independently, struggling to

achieve a goal without process.

Corsica - USA



39


To IPT or Not To IPT?

A Team with Focus!

Coordinated effort emphasizing individual

strengths. A process that provides new

ways of reaching a goal.

Corsica - USA



40


Integrated Product Teams Succeed!

Successfully applies skills and

technology, resulting in more

effective solutions.

Corsica - USA



41


Sample IPT Structure

Integrated

Product

Team

Contracting

Sourcing

Workspace Provisioning

Contract Management

Acquisition Support

Management

Budgeting

ROI Analysis

Cost Controlling

Human Resources

Architecture and Engineering

System Requirements

System Architecture and Design

Functional and Technical

Analysis

Implementation

Testing

Enterprise Systems

Infrastructure supportability

Installation

Operation

Maintenance

Process Engineering

Project Development Process

Coaching and Mentoring

Standards Development

Process Improvement

Quality Assurance

Auditing

Inspections

Defect Monitoring

Process Assessments

Technical Support

Program Control

Data Management

Configuration Management

Reliability and Maintainability

Customer Representatives

Business Requirements

User Interface Requirements

Customer Satisfaction

Assurance Migration

Support

Corsica - USA



42

Lesson #3 Project Management

Project Management

•What is Project Management?

• How is performed?

• Are there alternative?

• What works and what doesn’t?

Corsica - USA



43


What is Project Management?

Project Management is the execution of the total business

responsibility for an entire project.

A project is lead by a project manager who is the single

person within the organization who directs, controls,

administers and regulates all the activities of the project for

an organization.

A project manager is the individual who is ultimately

responsible to the customer and senior management and has

been given the authority to initiate required activities.

Corsica - USA



44


What is Project Management is NOT?

Project management is not just the collection of dates and

milestones and preparation of schedules.

Project management is not just the collection of financial

information about the project.

Project management is not just the collection of effort applied to a

project.

These activities are part of Project Control which is an activity

that projects must perform to understand their status.

Corsica - USA



45


How is Project Management Performed?

Project Management is performed by applying systematic

management and technical process to the problem of

producing a product that meets the customer’s

expectations of quality, on time and on cost.

Project management by committee is ineffective.

A single manager with the responsibility and authority to carry out the

project is required.

Corsica - USA



46


Are there alternative?

Yes!

A very costly project that produces a less then optimum

product or is a complete failure!

Corsica - USA



47


What works and what doesn’t?

•Obtain commitment from senior management and customer for

the project. In WRITING!!!

•Commit to quality. Everyone must be committed to pre-agreed

upon quality standards to make the project proceed smoothly.

•Follow a written and proven process defined for producing the

product desired. Evaluate performance against the process

regularly.

•Provide sufficient time to complete the project by following the

agreed to process and ensure everyone evolved is trained.

Corsica - USA



48



•Communicate regularly project objectives and status to all

effected groups.

•Document and report progress, changes in requirements or

objectives, and delivery dates.

•Make decisions! Project Managers must make and announce key

decisions affecting the project. Do not leave important matters to

chance.

•Measure, measure, measure! Continually measure the status of all

important activities and use the results to make decisions.

Corsica - USA



49



•Plan because scheduling is not enough. A detailed plan with rational for each activity is needed for success.

•Assign roles and responsibilities for each planned task and make people accountable for each task.

•Develop a process for resolving problem and follow it. Remember a problem is when an individual thinks it is a problem and it should be resolved not ignored.

•Plan to prevent defect before they occur by insuring the right processes, resources, trained individuals and management methods are use.

Corsica - USA



50



•Manage Change, change is a natural part of any project, whether

it is customer need, technology advancement, or some for of new

regulatory requirements imposed.

•Manage the schedule wisely. Watch for bunching up of items at

the beginning in the middle and especially at the end of the

schedule when there is no recovery time left.

•Commitments can only be made for resource under the projects

control. A manager cannot commit another departments resources,

staff, or equipment. Once an agreement to use resource, staff, or

equipment has been made then there is a quasi-ownership of them.

Corsica - USA



51


Project Reviews

•Reviews provide a means of risk reduction to ensure the delivered

product will perform the business function it was intended for.

•Reviews provide a forum to provide direction and feedback to the

project team.

•Reviews allow for the project team to demonstrate to the

customer and management their understanding of the product

requirements.

•Reviews allow for the project team to question customer needs

and present alternative solutions.

Corsica - USA



52


Risk Management

Risk is the probability of an undesired event occurring and

the effect of that event occurring.

Risk Management is conducting the process required to

prevent an undesired event from occurring and planning

alternative actions to minimize negative impacts to the

project if the undesired event does occur.

Corsica - USA



53


Risk Management

Remember!

A risk is an undesired event that may happen but has not yet

happen.

Once an undesired event (risk) occurs it is no longer a risk it

is a PROBLEM!

Corsica - USA



54


Risk Management

Three ways to experience risks

1. The product does not meet specified performance levels.

2. Actual costs are higher than budgeted.

3. Delivery of the product is too late.

Any of these may occur singularly or in combination!

Corsica - USA



55


Risk Management Five risk areas!

1. Technical risks

2. Supportability risks

3. Programmatic risks

4. Cost risks

5. Schedule risks

Any of these relate to one or more risk areas!

Corsica - USA



56


Risk Management

What to do!

1. Identify – Search for and locate risks before they become problems.

2. Analyze – Process risk data into decision making information.

3. Plan – Translate risk information decisions and actions (both present

and future) and implement those actions.

4. Track – Monitor the risk indicators and actions to take against risks.

5. Control – Correct for deviations from planned risk actions.

6. Communicate – Provide the visibility and feedback data internal and

external to the project on activates and current and emerging risks.

Corsica - USA



57


Risk Management

Methods!

While Risk Management methods are only limited by your

ability to imagine them. There are four categories of action.

1. Avoid Risk

2. Control Risk

3. Assume Risk

4. Transfer Risk

Corsica - USA



58


Risk Management

Avoid Risk!

Avoid Risk by selecting an alternative choice with lower risks

associated.

You may decided to use an older more proven technology or

to adapt the product design to meet capabilities provided by

commercially available modules.

Corsica - USA



59


Risk Management

Control Risk!

Control Risk by monitoring and correcting risky situations.

Develop a risk control plan and follow it.

You would identify those possible events that are Risks and

define acceptable parameters and thresholds of when action

must be taken to prevent an undesired event. Use reviews,

inspections , milestones, and backup plans as management

methods to control risk.

Corsica - USA



60


Risk Management

Assume Risk!

Assume Risk by making a conscious decision to accept the

consequences of the undesired event should it happen.

Some risk is always present within any project. It is up to the

manager to determine what level of risk is acceptable based on

the severity of any undesired events that the project could

incur.

Corsica - USA



61


Risk Management

Transfer Risk!

Transfer Risk by creating agreements were the avoidance and

consequences of an undesired event will be shared by others.

When we buy a product that comes with a warranty we are

sharing Risk with the manufacture. The manufacture is

sharing the risk of lower quality with us in return for profits.

While we are sharing the risk of product failure while we use it

in return for lower costs.

Corsica - USA



62


Project Closure

Project Closure involves the systematic shut down of a project

after the product has been delivered or at an earlier time when

it has been determined that the delivery of the product is no

longer of value to the customer.

Project closure should be a management activity that captures

data about the why the project was managed, analysis the data

in the context of the project’s success and/or failures and

provides usable information in the for of lesson learned.

Corsica - USA



63

Lesson #4

Engineering Standards

Corsica - USA



64

Lesson #4 Engineering Standards

Engineering Standards

Standardization is a management function for the coordination of

individual decisions with the objective of optimizing diversity.1

Thus Engineering Standards as applied to Software Engineering is a

mechanism to ensure that a everyone working on or managing a software

activity are following a previously agreed upon set of activities that has

known, expected, and accepted outcome.

1 Robert B. Toth, Then Economics of Standardization, 1984

Corsica - USA



65


Purpose of Engineering Standards

Most of us in the Information Technology industry usually

find ourselves speaking in technical terms. We find that most

of our managers are also speaking of technology when they

address software or hardware projects.

On the other hand executive management, our Directors,

Presidents, Vice-Presidents, CIOs, and CEOs are usually

talking about money. How much is that system is costing?

What is the Return on Investment (ROI) of your efforts.

Corsica - USA



66


Standards Translate technical problems into terms

Management can understand!

Engineering standards serve as the conduit of translation from things to money. That

must take place for engineering teams and management teams to work together

effectively.

Requirements

Size

Complexity

Training

Technology

Cost

Effort

Time

Market

Profit

Risks

Software

Engineering

Standards

Corsica - USA



67


Standards = The Bottom Line

Total Revenues

Total Investment Costs Return on Investment (ROI) =

Total Standardization Revenues

Total Standardization Investment Costs Standardization Gain =

Return on

Investment Profitability =

Standardization

Gain X

Standards can provide from a 10/1 to 20/1 ROI in Software Engineering

Corsica - USA



68


Technical Staff

Management

Top

Management

Engineers speak

Top

Managers

Speak

Mid

Managers

Speak

Corsica - USA



69


Setting Expectations

Engineering Standards are crucial in setting management and

customer expectations as to how and when a product will be

produced. Engineering standards can set the expectations for

and insure the realization of product quality.

Corsica - USA



70


Common Expectations

• Lower costs and greater profits.

• Reduction in number of unique implementation styles.

• More reusable applications and modules.

• Higher quality, user acceptability, and adaptability.

• Lower maintenance and easier enhancement capability.

• Development time reduced and faster time to market.

Corsica - USA



71


Justifying the need for standards.

How much is it costing us to use these standards?

Just start writing code!

It is not always easy to provide a direct economic analysis to

justify using standards because the standards effect processes

that often several levels of abstraction away from the

technical aspects of a project.

Corsica - USA



72


Justifying the need for standards.

Sometimes the use of standards is based on reducing

potential costs rather the reducing actual costs.

•Product certification is based on process standards.

•Regulatory issues require process and product standards be utilized.

•Distributed design and implementation environments require process and

product standards.

Corsica - USA



73


Can you go to far with Standardization?

An 19th century economist by the name of Vilfredo Pareto

identified a theorem know as the Pareto Principle. Which

identifies an upper limit of efficiency at about 80%.

Effort/Time Standardization

0.80%

0.20% 0.80%

0.20%

Corsica - USA



74


Unified Modeling Language (UML)

•The Unified Modeling Language (UML) is a standard for specifying,

visualizing, constructing, and documenting a software system.

•UML also provides a standard method for business modeling and for

modeling other non-software system components.

• The UML represents a collection of standard engineering methods and

symbols for the modeling of large and complex systems.

Corsica - USA



75


UML an open specification

•No industry standard modeling language.

•Prior modeling languages were similar with only minor difference in overall expressive power.

•Prior modeling languages shared a set of commonly accepted concepts and used different notations.

•Visual modeling was fragmented within the OO industry discouraging visual modeling methods by new OO users.

•Users demanded a standard for modeling language and modeling notation suitable for general-purpose usage.

Corsica - USA



76


UML is based on best practices

•Languages such as OMT, Brooch, and OOSE, which were in use by

software architects formed the basis for UML.

•Experience users of these prior languages can use UML with little

training.

•Adoption of a new standard language by an organization may require

some initial investment in training and technology transition.

• The benefit of encapsulating modeling notations and methods into an

industry standard language will more than compensate for the time spent

learning it.

Corsica - USA



77


Benefit of UML

• Improves project transition formerly concept phase to production and installation phases.

• UML is not a guarantee for project success but improves communication of project requirements and architecture.

• UML significantly lowers training and retooling cost when employees move on to new projects or organizations with in a company.

• Integration between tools, processes, and domains becomes not only possible but desirable and acceptable by all stakeholders.

• Creates a paradigm which encourages the focus on delivering business value to the customer by developers and management.

Corsica - USA



78


UML is a new standard for a new e-world

• Vague specification have been a large problem in the design and and operation of concurrent, distributed systems that have extremely complex interactions and are hard to understand, never mind predict.

• Specifications for standalone systems only affected that single system, when id didn’t work the risk of world catastrophic failure was low.

• Distributed concurrent business systems may have to interoperate with other systems halfway around the world. Both systems having been developed by people who have never heard of each other. A failure to communicate accurately can introduce errors that propagate around the World in a matter of seconds.

• These systems, many of which are real-time systems must operate continually regardless of errors, software/hardware failures or data corruption. You cannot simply reboot a distributed system with backup snapshot of the system from a prior state or point in time.

Corsica - USA



79


Standard Elements of UML

• Structural Diagrams

• Behavioral Diagrams

• Sequence Diagrams

• Collaboration Diagram

• State Notation

• Activity Diagrams

• Organizing Classes

Corsica - USA



80



• Structural Diagrams

– These diagrams are help the engineer visualize, specify, construct, and

document those characteristics of the system that are generally

constant or static over time.

• Types of Structural Diagram can include:

– class diagrams

– package diagrams

– object diagrams

– component diagrams

– deployment diagrams

Corsica - USA



81



• Behavioral Diagrams

– These diagrams are help the engineer visualize, specify, construct, and

document those characteristics of the system that are generally

changing, unstable, or dynamic over time.

• Types of Behavioral Diagrams can include:

– use case diagrams

– sequence diagrams

– collaboration diagrams

– state-chart diagrams

– activity diagrams

Corsica - USA



82



• Collaboration Diagrams

– These diagrams are help the engineer model the organization of the

interactive objects for the model.

• Types of Collaboration Diagrams can include:

– State, Event, and Signal diagrams

– Entry and Exit Actions diagrams

– Activities diagrams

– Initial and Final States diagrams

Corsica - USA



83



• Activity Diagrams

– These diagrams are help the engineer model the workflow or activity flow of the system and provide a visualization of detailed operations of the system.

–

• Types of Activity Diagrams can include:

– State diagrams

• activities

• actions

• transitions

• initial/final states

• guard conditions

– Flow diagrams

• branch and merge

• fork and join

Corsica - USA



84



• Collaboration Diagrams

– These diagrams are help the engineer model the the relationship

between classes, use-cases, and operations of system.

• Types of Collaboration Diagram Elements can include:

– Analysis Class

– Boundary Class

– Control Class

– Entity Class

Corsica - USA



85

Lesson #5 Software Product Life Cycle

Corsica - USA



86


Overview

In these discussions we will explore the fundamentals of

planning and managing software system development,

operations, and maintenance through the use of the

Software Product Life Cycle.

Corsica - USA



87


Questions to Answer

• What is a Life Cycle?

• Why is it used?

• What are the significant components?

Corsica - USA



88


What is the Software Life Cycle?

• The software system life cycle is the natural ordered sequence of activities

performed, formally or informally, to develop and maintain a software

system.

• The life cycle begins with a customer recognizing a business needs and

progresses through development, fielding, operation, and eventual

retirement.

Corsica - USA



89


Formulate

Need

Define

Concept

Demonstrate

& Validate

Requirements

Analysis

System

Architecture

Detailed

Design

Build

System

Migrate

System

Operated

System

Maintain

System


Decision

Point 1

Decision

Point 2

Decision

Point 3

Identify Needs

Gather User Requirements

Project Activation Funding Point

Validate Concept

Refine Requirements & Complete Project Documentation

Develop Funding Documentation

FUNDING POINT: Approval for System Development

Preliminary Design (high level)

Detailed Design

FUNDING POINT: Design Review and Approval to Build

Build or Acquire System


CHECK POINT: Physical Audit



System Maintenance


Corsica - USA



90


Formulate

Need

Define

Concept

Demonstrate

& Validate

Requirements

Analysis

System

Architecture

Detailed

Design

Build

System

Migrate

System

Operated

System

Maintain

System


Decision

Point 1

Decision

Point 2

Decision

Point 3

Decision

Point 1

Requirements

Analysis and

Management

Software

Design

Software

Implementation

Acceptance

Test

Decision

Point 2

Decision

Point 3

Decision

Point 1

Requirements

Analysis and

Management

Software

Design

Software

Implementation

Acceptance

Test

Decision

Point 2

Decision

Point 3

Installation and

Checkout

Decision

Point 4

Operation and

MaintenanceRetirement

Decision

Point 4

Decision

Point 5

Software

Development

Cycle

Software

Maintenance

Cycle

Corsica - USA



91


Questions to Answer


• Why is it used?


Corsica - USA



92


Why is a life cycle used?

• Product selection/elimination

• Product predictability

• Ability to sustain performance

• Resource and skill allocation

• Measurable management framework

Corsica - USA



93


Product Selection/Elimination

The primary purpose of the formalization of the Software

Product Life Cycle is to select those software products that

have the highest business value by eliminating the those of

least value as early as possible in the conception and

development phases.

Corsica - USA



94


• Business need

• Technical solution

• Process need

• Determine the actual business need.

“What problem are we trying to

solve?”

• Determine if the proposed

technology solutions are the right

ones for the business.

• The proposed system should match

the current business processes or

costs associated to change them

should be justified.

Corsica - USA



95


Process and Product Predictability

The Software Product Life Cycle helps management plan

business activities and project costs and revenues accurately.

This ability is critical to effective strategic planning and

market positioning, which leads to successful product release.

Corsica - USA



96


• Costs

• Delivery

• Quality

• Repeatability

• Product has to be on time every time,

with known production costs, and

with the quality the customer expects

built in.

• This ability has to be achievable form

contract to contract and delivery

order to delivery order.

• Indicators must be in place to let

senior management know

immediately of degradation in

abilities to perform.

Corsica - USA



97


Ability to Sustain Performance

The production of software products has many of the same

production issues associated with other products. The use of

a formal Software Product Life Cycle makes it possible to

plan for these issues and ensure solutions are available before

an issue becomes a problem.

Corsica - USA



98


• Authority

• Resources

• Training

• Accountability

• Process and sub process (work-flow) ownership can be assigned.

• Resources can be planned for and obtained in time to make the production of the product occur on time and at the budget costs.

• Software engineers and software programmers can be trained when necessary to perform the right functions at the right time.

• Roles and Responsibilities can be assigned and accountability for tasks maintained. Everyone knows what their job is and when each job is completed

Corsica - USA



99


Measurable Management Framework

The management of the effectiveness of Software Development activities

is critical to the business success of the development organization. A

single life cycle allows management to evaluate performance of various

techniques across time, technologies, projects, and customers to better

select successful business strategies.

Corsica - USA



100


• Measure

• Compare

• Evaluate

• Feedback

• Measure for the correct indicators that are linked to life cycle decision points.

• Compare data against previous sets from the same life cycle phases in other projects.

• Evaluate indicators to see desired effects of engineering and management standards are achieved.

• Project performance information can be compared across project in the organization to evaluate most profitable methods of management.

Corsica - USA



101


Questions to Answer


• Why is it used?


Corsica - USA



102


Phase 0 - Concept Initiation

This phase is characterized by the extensive amount of informal planning and brainstorming

activity that takes place. The system of this phase is a statement of needs (user

requirements) and a funding request for concept validation/demonstration and system

requirements analysis.

• User recognizes a business need

• Potential solutions explored

– Business Process Changes

– Product Changes

– Technology Insertion

• Funding and resource projections made

• Project timing explored

• Business risks identified

• Funding for proof of concept allocated

Corsica - USA



103


Phase I - Proof of Concept Phase

This phase is characterized by the cooperative efforts of business and technical to experts

ensure that proposed solutions will actually meet the business needs before costly system

development activities begin.

• Integrated project team is organized

• Proposed solution validated

– Systems modeled

– Prototypes evaluated

– Technology alternatives demonstrated

• User needs documented and agreed upon

• Refined concept/solution documented

• Functional requirements prepared

• Funding allocated for design/development phase

Corsica - USA



104


Phase II - Design/Development Phase

During this phase user needs are translated into detailed technical requirements in the form

of system design and software design documents, from which the system can be built or

acquired.

• System requirements are set

• System architecture is defined

• Software requirements allocated

• System requirements specification developed

• Software requirement specifications developed

• Build or acquire decision made

• Funding for production of system allocated

Corsica - USA



105


Phase III - Build/Deploy Phase

During this phase the system is built/acquired and deployed into the production environment

ready to be turned over to the system operations.

• Internal build activities begin

• System acquisition contracts let

• Components and system level testing completed

• System integrated into the production environment

• System installation and integration testing completed

• Physical audits and acceptance testing accomplished

• User/operator training conducted

• System turned over to systems operations

Corsica - USA



106


Phase IV - Operations/Maintenance Phase

During this phase the system is operated and maintained in the production environment and

ongoing user support is provided.

• Production and maintenance planning

• Production environment testing

• System operations

• User support and help desk

• Problem and modification analysis

• Modification implementation

• Maintenance review/acceptance

• Migration

• Software/System retirement

Corsica - USA



107


Project Management Review should be held on a monthly basis.

Preliminary

Statement

of Need

Draft Project

Management

Plan

Draft

Statement

of Need

Draft Quality

Assurance Plan

Draft Configuration

Management Plan

Quality

Assurance Plan

Configuration

Management

Plan

Verification and

Validation Plan

(SVVP)

Project

Management

Plan

Funding

Document

Draft

Verification and

Validation Plan Draft System

Requirements

Specification

Draft Software

Requirements

Specification

Software

Requirements

Specification

Software

Requirements

Review (SRR)

Virtual

Review

System

Requirements

Specification

Funding

Point III

Funding

Point II

Development

Funding Point

Virtual

Review

Draft

Funding

Document

Funding

Point I

Corsica - USA



108


Formulate

Need

Define

Concept

Demonstrate

& Validate

Requirements

Analysis

System

Architecture

Detailed

Design

Build

System

Migrate

System

Operated

System

Maintain

System


Decision

Point 1

Decision

Point 2

Decision

Point 3

Preliminary Design

Verification

Requirements

Verification

User Need Defined

Validation

Detailed Design

Verification

Build

Test

Migrate

System Test

Operate and

Maintain Improve

Migrate

System Test

Preliminary Design

Verification

Preliminary Design

Verification

Requirements

Verification

Requirements

Verification

User Need Defined

Validation

User Need Defined

Validation

Detailed Design

Verification

Detailed Design

Verification

Build

Test

Build

Test

Migrate

System Test

Migrate

System Test

Operate and

Maintain Improve

Operate and

Maintain Improve

Migrate

System Test

Migrate

System Test

Water Fall

Spiral

Corsica - USA



109


Formulate

Need

Define

Concept

Demonstrate

& Validate

Requirements

Analysis

System

Architecture

Detailed

Design

Build

System

Migrate

System

Operated

System

Maintain

System


Decision

Point 1

Decision

Point 2

Decision

Point 3

The Rational

Unified Process®

or RUP®

Business Modeling

Requirements

Analysis & Design

Implementation

Test

Deployment

Configuration and

Change Management

Project Management

Environment

Corsica - USA



110


Better

Cheaper

Faster

Software Products that are:

Corsica - USA



111

Lesson #6 Supporting Disciplines

Quality Assurance

Supporting displaces are those engineering functions that are

required to complete a software project but are not directly

responsible for the design and implementation. Without these

engineering activities software projects would become

unmanageable.

Corsica - USA



112


Quality Assurance

Quality Assurance is an engineering discipline focused on the

identification and prevention of defects before they enter a

product.

Often Quality Assurance (defect prevention) is confused with

Quality Control (testing) an activity of Software Engineering.

This can led to confusion within engineering groups and to

higher defect and rework cost due to defects not be eliminated

until after a product is implemented.

Corsica - USA



113


Quality Assurance Process Assurance

Quality Assurance is “. . . the set of systematic activities providing the evidence of the ability of the software process to produce a software product that is fit for use.”1

Quality Assurance is the eyes and ears of management, providing unbiased feedback on process compliance, early enough that process lapses can be addressed in time to have positive results. Quality Assurance provides management with an early warning indicator of risks to the product quality (usability, function, and suitability) and can identify process changes that will result in a quality product being delivered. 2 1. G. Gordon Schulmeyer, et al, The Handbook of Software Quality Assurance 2. Watts S. Humphrey, Managing the Software Process (The SEI Series in Software Engineering)

Corsica - USA



114


Quality Assurance Process Assurance

It is essential that the Quality Assurance personnel have a reporting path which is independent of the management responsible for the activities audited and the associated daily conflicts generated by schedule and budget. Independent oversight, through various methods, encourages adherence to the standard software process that have been proven. It also allows for introduction of improvement opportunities to the software processes. Locating an appropriate level of management where Quality Assurance will have frequent access, active support, and be above the conflicts of interest is essential to the success of a software product organization. 1

1. Watts S. Humphrey, Managing the Software Process (The SEI Series in Software Engineering)

Corsica - USA



115


Software Quality Assurance

Quality Assurance should be an

integrated part of any software

development effort. Quality

Assurance (QA) teams should be

under management independent of the

project manager but have full access

to all project activities and artifacts.

The QA team is to monitor and verify

that standards, methods, and processes

are properly followed by the project

team and deviations are documented

for future consideration and review.

Software Quality Assurance in an Organization.

Software

Quality

Assurance

Software

Process

Management

Software Project

Management

Enterprize

Systems

Business

Organizations

Senior

Management

(CIO)

Corsica - USA



116


Why does this model produce problems rather then quality?

Software

Quality

Assurance

Module

Leader

Module

Leader

Project 1

Manager

Project 2

Manager

Software Project

Management

Main Frame Network

Systems

Enterprize

Systems

Software

Process

Management

Human

Resources

Finance

Business

Organizations

Senior

Management

(CIO)

Corsica - USA



117


Quality Assurance

Process Assurance

The methods typically used to accomplish process assurance

include:

• Quality Audits

•Error Detection

•Quality Assessment

•Statistical Process Control Analysis.

Corsica - USA



118


Quality Assurance

Quality Audits

SQA Audits are performed to “determine the adherence to established

standards and procedures.”1 Evaluation of the sufficiency or effectiveness

of the procedures or standards is part of an SQA audit.

An SQA audit examines artifacts and records, according to an agreed

sampling process to determine if procedures are being followed correctly.

Audit are regularly performed by external auditors who are not part of the

software project.

1 NASA Goddard Space Flight Center, “Software Quality Assurance Audits Guidebook”

(http://satc.gsfc.nasa.gov/audit/audgb.txt)

Corsica - USA



119


Quality Assurance Error Detection

Formal Inspection is an examination of a product during the development process, typically inspections provide the most benefit when they are done early in the concept and design phases. The objective is to identify defects in the product before it has completed development. Inspections are usually most effective when conducted by Quality Assurance Personnel with technical training and hands on experience with the technology being used. Inspections may use many of the techniques of testing to identify errors and potential design or implementation flaws. Certain projects which have an effectively performing inspection process report better than 80% defect detection rates.1

1 Tom Gilb and Dorothy Graham, Software Inspection (Wokingham, England: Addison-Wesley Publishing), 1993

Corsica - USA



120


Quality Assurance Error Detection

Peer Reviews are formal meeting at which an artifact, or a set of artifacts are presented to the user, customer, or other interested parties for comments and approval.1

Peer Reviews when implemented provide opportunities for people to discover errors in products before release, learn alternative techniques for design and implementation from other groups. Peer Reviews also provide a way to standardize architectural styles and methods among various groups within an organization. In serve as a vehicle for the continuing improvement of these capabilities. In addition more junior members of the project teams can be mentored by senior members present. The formal structure of a peer review requires the following participant roles: the moderator ; the recorder ; the presenter ; and the reviewers.

Corsica - USA



121


Quality Assurance

Error Detection

Walkthroughs are informal peer review meetings in which the primary

developer or author of the software product acts as presenter to proceed

through the material step by step.

The objective is to raise or identify design issues or implementation issues

and to offer recommendations for solutions and improvement.

Unlike inspections and formal peer revise walkthroughs are intended to be

informal and operate more like a brainstorming and review session combined.

Corsica - USA



122


Quality Assurance

Error Detection Testing is a very formal evaluation technique, which has as its objective the detection

of errors in a completed product, module, or unit. Thus data collected during testing

can be used to help prevent errors in future development but cannot prevent errors in

the current item under testing, it can only find errors because the item is already

complete. The item will have to be reworked to fix any errors.

Testing by definition is the execution of the software and the evaluation of its

resulting actions in response to a set of predetermined inputs against documented

expected outputs.

Testing is often confused as Quality Assurance but in general testing is a Quality

Control function within the Software Product Engineering Process and should

not be considered a Quality Assurance function. When testing like techniques are

applied by Quality Assurance it is considered an Inspection.

Corsica - USA



123


Quality Assurance Assessments

Assessment is a Quality Assurance activity that is used to determine and understand the capability of a process and an organization’s ability to implement the process, by evaluating it against a known industrial standard. Assessments use a combination of techniques from inspections, audits, reviews, and statistical process controls measure an organizations ability to satisfactorily perform software processes. Assessments provide management with insight into the ability of the software teams to implement and sustain various levels of quality within their software engineering processes, thus resulting in software products of a know quality. There are several industry recognized methods for conducting assessments within software organization including: ISO 9001, 9000-3 ; SPICE ; and SEI-CMM.

Corsica - USA



124


Quality Assurance Analysis

Root Cause Analysis identifies the process weaknesses that allowed product defects to be inserted originally, to prevent reoccurrence of the these types of defects in the future.

To accomplish Root Cause Analysis a team of individuals, which may include developers and other analysts, analysis failure and trend reports to determine where and why defects are inserted into the product. If the cause is systemic and repeatable, a remedy to decrease the risk of reoccurrence of similar defects, within similar products under similar circumstances must be identified and implemented.

Results of Root Cause Analyses performed by Quality Assurance, provides valuable inputs for process improvement planning and must be passed on to the process management and improvement team.

These activities may be performed at various stages of the software life cycle, but it is recommended that the elapsed time between defect discovery and this type of analysis be minimized.

1

1 Tom Gilb and Dorothy Graham, Software Inspection (Wokingham, England: Addison-Wesley Publishing, 1993)

Corsica - USA



125


Quality Assurance Analysis – Cause and Effect Chart

Corsica - USA



126


Quality Assurance Historical Example

1976 1977 1978 1979 1980 1981 1982 1983 1984 1985 1986 1987 1988 1989 1990 1991 1992 1993 1994 1995 1996 1997 1998

Structuredflows

Formal softwareinspections

Formal inspectionmoderators

Formalizedconfiguration control

Inspection improvements

Configuration ManagementData Base (CMDB)

Error Counting, Metrics

Formal Process

Error Cause Analysis

Process Analysis

Quality Management and Process Enhancement

Oversight analysis

Build automation

IBM process assessment

Formalizedrequirements analysis

Quarterly qualityreviews

Prototyping

Inspectionimprovements

Formalrequirementsinspections

Processapplied tosupportsoftware

FSW (recon)certification

LAN based developmentenvironment

Enhanced test tools

Oracle based CMDB upgrade

ISO 9001 certification

Project manager process reviews

Process improvement database

Concurrent engineeringprocess model

Formalized milestonerisk assessments

Support softwareinspection processautomation

Re-engineeringlessons learned

Web-basedtroubleshootingguide

On-lineprogrammingstandards

SEI SPCcollabora-tion

Reliability modeling

Process maturity measurements

Formalized training

Technical exchange seminars

Process evaluation

Software developmentenvironment

Process documentassessment

Reliability/complexityresearch

Developmenttest philosophy

Inspectionprocesstools

Groups_graphics_pubs_PASS_FSW_001.cv5

Structurededucationplanning

Formalizedlessonslearned

Quality Assurance Induced Process Improvement History from Space Shuttle Program

Corsica - USA



127



Reliability Prediction is: “The ability of the software to perform its required function under stated conditions for a stated period of time.”1

Management can use accurate prediction of software system reliability to better plan quality assurance and quality control activities and to determine a system’s readiness for release to the customer. In determining an estimate for reliability we use the 3 basic measurements: actual failure data records ; results of a random sample of inputs ; and number of actual and induced faults detected during testing. The negatives to reliability prediction are the need for a large data base of error information for similar systems and the advancement of technologies that introduces new system types and technologies faster then sufficient error data can be collected and analyzed. 1 IEEE Standard Glossary of Software Engineering Terminology, IEEE-STD-610.12-1990 (New York: IEEE, 1991).

Corsica - USA



128



Statistical Process Control is the use of statistical methods to assure both process and product quality. These methods include: Pareto analysis a method that seeks to discover from an analysis of defect reports those critical few causes that are responsible for most of the reported problems. 80% of reported problems can usually be traced to 20% of the known causes. By rectifying the vital 20%, you have the greatest impact on quality. Shewhart control charts are used to determine and display statistical control limits for samples taken at predetermined intervals of time. Scatter Diagrams reveal relationships or association between two or more variables. The relationship among the variables is manifest themselves any non-random structure in the plot.

Corsica - USA



129


Quality Assurance

Analysis – Pareto Chart

Purpose Of A Pareto Chart

A pareto chart is used to graphically summarize and display the

relative importance of the differences between groups of data.

Corsica - USA



130


Quality Assurance

Analysis – Shewhart Chart

Shewhart X-chart with control and warning limits

Corsica - USA



131


Quality Assurance

Analysis – Shewhart Chart

Shifting patterns: Shifts may result from introduction of

new programs and engineers, process changes, new

technologies and or software changes. They also could be

from a change in SQA methods, standards, or from a process

improvement.

Trending patterns: Trends are usually due to a gradual patching, data

degradation or, requirements instability, lack of process control. They

also could be from a change in SQA methods, standards, or from a

process improvement.

Corsica - USA



132


Quality Assurance

Analysis – Scatter Charts

Scatter Plot:

Variation of Y

Does Not

Depend on X

(homoscedastic)

Scatter Plot:

No Relationship

Scatter Plot:

Strong Linear

(positive

correlation)

Relationship

Scatter Plot:

Quadratic

Relationship

Documents

Software Engineering Course