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 IndoTech@indotechsolutions.com
Software Engineering
University of Corsica
March-April 2002
by
Robert L. Straitt
Organizational Performance Architect
8362 Tamarack Village 119-145, Woodbury, MN 551125, USA
Tel 612-747-6300 rstraitt@indotectsolutions.com

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-based
TQM
Philosophy
Procedures
Training
People
Methods
Case
Tools
- 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 estimation 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 isDifferent Than
Software-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
Maintenance
Retirement
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
Structured
flows
Formal software
inspections
Formal inspection
moderators
Formalized
configuration control
Inspection improvements
Configuration Management
Data Base (CMDB)
Error Counting, Metrics
Formal Process
Error Cause Analysis
Process Analysis
Quality Management and Process Enhancement
Oversight analysis
Build automation
IBM process assessment
Formalized
requirements analysis
Quarterly quality
reviews
Prototyping
Inspection
improvements
Formal
requirements
inspections
Process
applied to
support
software
FSW (recon)
certification
LAN based development
environment
Enhanced test tools
Oracle based CMDB upgrade
ISO 9001 certification
Project manager process reviews
Process improvement database
Concurrent engineering
process model
Formalized milestone
risk assessments
Support software
inspection process
automation
Re-engineering
lessons learned
Web-based
troubleshooting
guide
On-line
programming
standards
SEI SPC
collabora-
tion
Reliability modeling
Process maturity measurements
Formalized training
Technical exchange seminars
Process evaluation
Software development
environment
Process document
assessment
Reliability/
complexity
research
Development
test philosophy
Inspection
process
tools
Groups_graphics_pubs_PASS_FSW_001.cv5
Structured
education
planning
Formalized
lessons
learned
Quality Assurance Induced Process Improvement History from Space Shuttle Program

Corsica - USA
127
Quality Assurance
Analysis
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
Quality Assurance
Analysis
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

Software Engineering Course

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Destaque

Destaque (6)

Semelhante a Software Engineering Course

Semelhante a Software Engineering Course (20)

Mais de Dr. Robert L. Straitt

Mais de Dr. Robert L. Straitt (6)

Software Engineering Course