Strategies for Solving Software Problems

1
Strategies for Solving Software Problems

• Presented by
• Jim Harris
• David Mancy
• ISM 6930 Prof. James Jiang

November 14, 2006
2
Presentation Outline

• Introductions
• The book Strategic Software Engineering
• (by Deek, McHugh and Eljabiri)
• Focus on Section II Strategies for Solving
  Software Problems
• Detailed review of major points from each Chapter
  in Section II
• Summary and Conclusions
• Open Forum

3
Key Terms in Section II

• Software Engineering The application of a
  systematic , disciplined, quantifiable, approach
  to the development, operation, and maintenance of
  software (IEEE).
• Problem A problem exists whenever a gap is
  present between an initial or current state and a
  desired state (Hewitt, 1995).
• Solution The final step in the problem-solving
  process. Goals should have been achieved and the
  problem should have been mitigated.
• Diversity Differences in cultural or personal
  background professional experience problem
  perspective understanding or technical and
  disciplinary capability.
• Ignorance Lack of data or inaccurate data
  (including lack of knowledge about available
  tools) that prevent problems from being well
  defined or understood.

4
Section II Strategies for Solving Software
Problems

• Ch. 6 - The Problem-Solving Process
• Ch. 7 - Software Technology and Problem Solving
• Ch. 8 - Evolution of Software Development
  Strategies
• Ch. 9 - Diversification of Problem-Solving
  Strategies in Software Engineering
• Ch. 10 - Strategies at the Problem Engineering
  Level

5
Ch. 6 - The Problem-Solving Process

• What Is a Problem?
• What Is Problem-Solving?
• What Is a Solution?

6
What is a Problem?

• A problem exists whenever a gap is present
  between an initial or current state and a desired
  state (Hewitt, 1995).

Desired Situation (Goal)
Initial Situation (Existing)
Problem Solving Process
Figure The problem solving process from initial
situation to final goal.
7
What is a Problem (cont.)

• A well-defined problem statement contains three
  principal elements goal, givens, and unknowns.
• Goal what one wants to accomplish
• Givens specific facts that must be identified
  prior to solving the problem.
• Unknowns must be found out/resolved in order to
  accomplish the goal.

8
Five Types of Business Environment Problems

• Problems of Meeting Standards
• Problems of Selection Between Alternatives
• Problems of Customer Satisfaction
• Problems of Goal Achievement
• Problems of Goal Evolution

9
What is Problem Solving?

• The process by which a situation is analyzed and
  solutions are formed to solve a problem, with the
  steps taken to resolve, eliminate, or mitigate
  the problem.

10
Typical Problem-Solving Process

• Define the Problem
• Analyze the Situation
• Generate Ideas
• Analyze the Ideas
• Make a Decision
• Implement the Solution

11
Decomposition of a Problem
Solvable Sub Problem
Sub Problem
Solvable Sub Problem
Complex Problem
Solvable Sub Problem
Sub Problem
Solvable Sub Problem
12
The Problem-Solving Process Using Reusable
Components (OO)
Library of Reusable Components

Class Object
Class Object
Class Object
Class Object
Class Object
Problem Solving Process
Problems
Solutions
13
What is a Solution?

• The final step in the problem-solving process
• Goals should have been achieved and the problem
  should have been mitigated.

14
Problems Solutions in the Old Business
Environment

• Adam Smith (1776) Division of Labor
• Frederick Taylor (late 1800s) Production Line
• Edward Deming (1940s) Total Quality Management
  (TQM)

15
Problems Solutions in the Information Age
I.T.s Effects

• New Opportunities in Sales Marketing
• Rapid Product Development
• Abbreviated Product Life Cycles
• Changes in Management Methods Techniques
• Reshaping Organizational Structures to Respond to
  Global/Local Needs

16
Ch. 7 - Software Technology and Problem Solving

• Software Technology as an Enabling Business Tool
  What Computers Can Do
• Software Technology as a Limited Business Tool
  What Computers Cannot Do

17
What Computers Can Do

• Software Technology
• Software Benefits to Business
• Portability Power
• Connectivity Power

18
Software Technology

• Helps Visualize Problems
• Facilitates Communication Among Problem Solvers
• Creates a Collaborative Environment
• Frees the Problem-Solving Process from Dependency
  on Location, Distance, or Time.
• Provides Effective Tools for Collecting
  Analyzing Data.

19
Software Benefits to Business

• Simplification of Business Structures
• Removal of Unnecessary Processes
• Overall Quality Improvement
• Reduction in Time to Market
• Organizational Flexibility
• Cost Reduction
• Bringing the Benefits of a More Innovative
  Business Culture.

20
Portability Power

• One Can be Connected to the Business Environment
  Virtually Anywhere.
• Online Dynamic Databases Eliminates the Need for
  Live Contact to Check Inventory.
• Paperwork Reduction Digital Archiving

21
Connectivity Power

• Facilitates Communication Between Devices in a
  Multi-Media Fashion.
• A Computer Can Be Connected to Multiple Devices
  PDA, TV, Scanner, Printer, etc.
• Multi-Media Data Can Be Captured Immediately and
  Sent to a Business Partner in Almost Real Time.

22
What Computers Cannot Do

• People Have Needs That Change Over Time
• Most Users Do Not Understand Computer Languages
• Decisions Problems Complex Ill-Structured
• Software is a Black Box for Creating Economic
  Value

23
People Have Needs That Change Over Time

• Software is Limited in Recognizing Differences of
  Individual Styles.
• Reasons Include
• Use of Different Cognitive Styles When
  Approaching Problem Solving.
• Variations in Background, Culture, Values, etc.
• Different Goals, Ambitions, and Risk-Management
  Strategies.
• Assorted Levels of Involvement and
  Responsibilities in the Business Organizations
  Process.

24
Most Users Do Not Understand Computer Languages

• Software Code Writers Use Technical Languages to
  Express the Solution.
• In Many Cases, the Software Code Writers Do Not
  Thoroughly Investigate Whether Their Final
  Product Reflects What the End Users Needed.

25
Decisions Problems Complex and Ill Structured

• Complex Organizations Have More Ill-Structured
  Problems.
• The I.T. Technical Requirements Become Harder to
  Address.

26
Computers Cannot Work Without People

• Software is Produced and Based Upon People Needs.
• Software that Does Not Create Value Will Not
  Survive in the Marketplace.
• Computers Cannot Adjust to Real Situations.
• Computers Do Not Think
• The Goal of Software is to Solve Problems of
  People.

27
Ch. 8 - Evolution of Software Development
Strategies

• Current Challenges to Software Development
• Competing Views of Software Development
• The Engineering of Software
• The Process and the Model
• Progression in Software Engineering Strategies

28
Current Challenges to Software Development

• Surviving in an Extremely Competitive Market
• User Power Authority
• Market Share
• Killer Applications
• The Anytime-Anywhere Factor
• The Return on Investment (ROI) Factor
• The Technology Factor

29
Competing Views of Software Development

• Business Can Make Software Better
• Software Can Make Business Better

30
The Engineering of Software

• Appropriateness
• Value Maximization
• Effective Strategy
• Modeling

31
The Process and the Model

• Software Process The Technical and Management
  Framework Established for Applying Tools,
  Methods, and People to the Software Task.
  (Humphrey Kellner 1989)
• Process Model A Specification of a Real-World
  Software Process (i.e. SDLC)(Jaccheri, Picco,
  Lago 1998)

32
Progression in Software Engineering Strategies

• Era of Management Isolation
• Era of Traditional Software Engineering
• Era of Business Evaluation of Software
  Engineering
• Era of Business-Driven Software Engineering

33
Era of Management Isolation

• Duration 1960s late 1970s
• Technology large computers
• Management/Business Involvement lack of
  involvement and dependency on computer
  professionals.
• Software Development Process the value of
  software is in the software.
• Nature of Applications large systems
  structured problems.
• Team Structure 100 technical team.
• Process Life-Cycle Models Developed Waterfall
  Method

34
Era of Traditional Software Engineering

• Duration mid to late 1970s
• Technology database, networking, and
  communications technology
• Management/Business Involvement Initial systems
  analysis, testing, and documentation
• Software Development Process Business metrics
  incorporated (no human-driven factors)
• Nature of Applications Management Information
  Systems (MIS) and Decision Support Systems (DSS)
• Team Structure Technical and some business
  analysts.
• Process Life-Cycle Models Developed Modified
  Waterfall

35
Era of Business Evaluation of Software Engineering

• Duration 1980s
• Technology PC computing
• Management/Business Involvement Business and
  software teams
• Software Development Process Critical business
  investment
• Nature of Applications Desktop applications
  packages
• Team Structure Technical but monitored by
  business managers
• Process Life-Cycle Models Developed Spiral Model

36
Era of Business-Driven Software Engineering

• Duration 1990s and onward
• Technology The Internet
• Management/Business Involvement Management
  partners with software teams with high end-user
  involvement.
• Software Development Process Value
  creation-driven software process
• Nature of Applications Web-based, wireless,
  heavy focus on end-user interface
• Team Structure Tailored to the needs of the
  development process
• Process Life-Cycle Models Developed Rapid
  Application Development (RAD), Commercial
  Off-the-Shelf Software (COTS), etc.

37
Ch. 9 - Diversification of Problem-Solving
Strategies in Software Engineering

• Understanding Diversification in Software
  Engineering
• The Hidden Value of Differences
• Integration Not Differentiation
• Diversity in Problem Solver Skills at the Project
  Management Level
• Diversity as Value-Adding Tool in Problem Analysis

38
Understanding Diversification in Software
Engineering

• Driving forces at the problem level
• Scope and complexity of problems
• Types of requirements and forms of problems
• Need to learn and apply new capabilities
• Challenges of continuous change
• Impact of the consumer economy and
  interdisciplinary effects
• Development of e-business applications
• Multiplicity of stakeholders, project team
  skills, background requirements, and business
  goals

39
Understanding Diversification in Software
Engineering

• Driving forces at the solution level
• Project management approaches
• General standards
• Quality-assurance standards
• Hardware and software tools
• Networking tools
• Data mining and automation tools
• Nature, scope, and domain of applications
• Need for business-driven software engineering
• Secure software engineering
• Killer applications
• Mobile or wireless software engineering

40
Impact of time and interdisciplinary impacts on
the evolution of process modeling
41
Hidden Value of Differences

• Conventional problem solving
• Eliminate sources of contradiction
• Eliminate or minimize the difference in favor of
  specialization
• Integrative cutting-edge problem solving
• Capitalize on differences to obtain optimized
  solutions
• Incorporate differences by inclusion

42
Negative vs. Positive Differences

• Are differences valuable and relevant?
• If not, exclude them
• If so, they should be utilized, not ignored or
  eliminated

43
Modalities that affect interpretation of
differences

• Simultaneity factor
• Differences can appear contradictory when they
  occur simultaneously
• Actually complementary when placed in sequential
  order
• Unique answer factor
• Appear contradictory if only one element of a
  situation is taken as representative of the
  entire situation
• Leaves no room for other contributing factors
• No way to find relationships between diverse
  differences

44
Integration Not Differentiation

• Example Which is more important the process or
  the project?
• Misguided alternative
• Implies differentiation is the only choice
• Integration is out of the question
• In reality
• No process exists without a project
• No project can have a successful outcome without
  a systematic problem-solving process

45
Interdisciplinary Ignorance

• Lack of data (or presence of inaccurate data)
• Lack of knowledge about available information
  and/or tools
• Hinders proper understanding of problems
• Thorough grasp of a problem and solution results
  in success
• Ignorance masks or obscures the real situation
  and broadens the distance between actual problems
  and appropriate solutions

46
Interdisciplinary Ignorance

• Sources of ignorance
• Unreliable sources of information
• Partial knowledge
• Lack of communication
• Inter-organizational ignorance
• Unprocessed, unused, untailored or vague data
• Politically based ignorance
• Technically based ignorance
• Statistically based ignorance
• Illusion based ignorance

47
(No Transcript)
48
Levels and Types of Diversity Deployment
49
Ch. 10 - Strategies at the Problem Engineering
Level

• Identifying Interdisciplinary Resources and
  Comprehensive Problem Identification
• Data Collection Phase
• Data-Processing Phase
• Information Presentation Phase
• Strategies in Software Engineering

50
(No Transcript)
51
(No Transcript)
52
Summary and Conclusions

• From Chapter 6
• Problem solving can benefit greatly from
  incorporating an appreciation for diversity as a
  core value Although diversity has historically
  often precipitated conflict and exclusion, from a
  problem-solving point of view, it presents an
  irreplaceable opportunity to develop broader,
  more encompassing, and integrated approaches to
  solving problems. By learning to view diversity
  as an asset rather than as a barrier or obstacle,
  one can become motivated to understand problems
  in an interdisciplinary manner and to capitalize
  on the ability of diversity to identify and
  enable the creation of better solutions.

53
References

• Deek, Fadi P., McHugh, James A.M., Eljabiri,
  Osama M (2005), Strategic Software Engineering,
  Boca Raton, FL, Auerbach Publications.

54
(No Transcript)