Software Problem Solving with Pólya Approach

Software Activities and Tasks

• There are four software activities per System Development Life Cycle (SDLC).
• Each activity contains a set of tasks.
• Activities also include deliverables.
• Combination and sequence of activities and tasks defines the project's software process.
• Problem-solving techniques are needed to solve tasks.

Why Problem-Solving?

• Software engineers are professional problem solvers.
• A problem, if left unresolved, hinders reaching a goal.
• A problem exists with an undesirable state and a desirable state.
• Problem-solving moves undesirable states to desirable states.
• There are many problem-solving processes and techniques.

Problem-Solving Processes

• All problems are solved by implementing a process.

Pólya Approach to Problem Solving

• One such process is Pólya Approach.
• The Pólya Approach is "The System's Approach to Problem Solving."
• Proposed by Mathematician George Pólya.
• There are 4 steps in the Polya approach:
• Understanding the problem.
• Devising a plan to solve it.
• Carrying out that plan.
• Looking back at the solution to evaluate efficacy.

Polya Approach Step 1: Understanding the Problem

• "A problem well stated is a problem half solved."
• This step is often neglected.
• Many have experienced solving a problem and later realizing they misunderstood it.
• Not understanding the problem results in an inadequate or incorrect solution.
• Clarifying the problem early provides excellent investment in the long run, and results a successful first attempt.

Polya Approach Step 2: Devising a Plan

• Some problems have multiple ways to solve.
• Skills are needed to choose the best approach.
• Skills include making lists, identifying probable courses of action, eliminating unlikely courses of action, and creating pictures or models.
• Problem-solving techniques will be addressed after Step 4

Polya Approach Step 3: Carrying Out the Plan

• Execution is not the same as following the plan from start to end.
• A plan implies intention, not a surefire outcome.
• A plan is what to expect in solving a problem.
• Not all plans work as expected.
• Adjust the plan and try again as needed.
• If the plan does not lead to the correct solution, be willing to abandon it and choose another.

Polya Approach Step 4: Looking Back

• Determine which parts of the solution worked and which did not.
• Allows adjustment of the current solution.
• Helps in learning more about solving similar problems in the future.

Problem-Solving Techniques

• There are many general techniques.
• In SWE, many are used within the software development process.
• They help move from undesired states to desirable ones.
• Many SWE problems are simply part of the process.
• Scheduling a project, gathering the correct requirements, or choosing the best coding methods.
• Similarly, many problems are just a natural part of life:
• Preparing a meal, getting to work, etc.
• Problems are not inherently negative.
• Common techniques in SWE:

Problem-Solving Technique: Abstraction

• Abstraction involves two steps:
• Solve a model problem first.
• Apply the solution to the actual problem.
• Example:
• Build non-working prototypes and draw networks, data, and process models.
• Implement the actual items.
• The prototypes and models represent solutions to real-world problems in abstract.

Problem-Solving Technique: Analogy

• Analogy means adapting a solution to a similar problem from the past.
• Google, Stack Overflow (overtaken by ChatGPT), can be used for solutions. Although, they may not provide exact solutions/code.
• Example:
• Finding how to print textwidth in LaTeX in inches.

Problem-Solving Technique: Brainstorming

• Brainstorming is spontaneous:
• Generate ideas for solving the problem.
• Evaluate the generated ideas.
• Apply the best ideas for solving the problem.
• In step one, merit is not evaluated and all ideas can be offered freely.
• Joint Application Development (JAD) is an example.
• Key people generate potential software requirements for the system.
• After combined, developed & refined, official requirements are formed.

Problem-Solving Technique: Divide-And-Conquer

• Divide and conquer involves dividing a problem into manageable parts:
• Break a large/complex problem into smaller/easier problems.
• Solve those problems.
• Integrate the solutions to form an overall solution.
• Example:
• Proposed Software System broken down into Functional components, then Classes/ methods/ functions.

Problem-Solving Technique: Drilling Down

• Drilling down is to increasingly detail parts of the problem until the source of problem is found & solved.
• Example:
• Fix an end-user-reported error by observing the problem in the user interface.
• Most general sign of the problem.
• Drill down through a hierarchy of classes and methods and find the logic defect and fix it.

Problem-Solving Technique: GROW Model

• GROW model involves four steps:
• State a goal
• Evaluate the current reality regarding the stated goal.
• Identify the obstacles that hinder the progress toward the goal and the options available for working around those.
• Determine on a Way Forward to accomplish the goal, based on the reality of the obstacles/options analysis

GROW Model example

• Deadline problem, 3 months to go, 6 months to complete project.
• Goal: Complete the project on time.
• Reality: Not meeting the original deadline
• Obstacles: Impending deadline, the current software process, length of work week, and number of people on the project.
• Options:
• Change to a new deadline with detailed estimate of effort to complete project.
• Propose to release the software system in increments.
• Require overtime from team members.
• Add more people to the project
• Way forward is to decide on one of the available options.

Problem-Solving Technique: Hypothesis Testing

• Hypothesis testing refers to assuming a solution and then trying to prove or disprove that solution.
• For example, writing a segment of code and hypothesize on its correctness based on prior logical evidence.
• Test the hypothesis by compiling and testing the code.

Problem-Solving Technique: Means-Ends Analysis

• Means-Ends Analysis chooses an action at each step to move the process closer to solution.
• Means-Ends Analysis can be used for large and complex projects.
• Technique - "Macros and micro scheduling".
• Micro scheduling create a detailed schedule of part of the project in the near future.
• Macro scheduling only creates a general schedule for parts to complete in the more distant future.

Problem-Solving Technique: Research

• Research is to find and analyze information that helps solve a problem.
• Early in the software development process, decide the best way to implement the solution to an existing problem.
• Options
• Purchasing/leasing a commercial-off-the-shelf system (COTS).
• Contracting the services of an application service provider (ASP).
• Subscribing to a software-as-a-service (SaaS) application.
• Hiring a consultant to develop a custom system.
• Developing a custom system in-house.
• Modifying the current system if one exists.

Problem-Solving Technique: Research (Decision Analysis)

• To choose the best option, conduct a decision analysis
• Identify candidate solutions to the problem.
• Analyze them.
• Compare them side by side.

Problem-Solving Technique: Reverse Brainstorming

• Reverse brainstorming shifts focus to how to cause the problem or how to make the problem worse.
• Then create solutions to avoid the "reverse problems.".
• Involves six steps:

1. Write a general problem statement.
2. Ask a big-picture question.
3. Ask the reverse question.
4. List reverse solutions.
5. List potential solutions.
6. Combine potential solutions.

Example of Reverse Brainstorming

1. Problem statement is the current change control process is error-prone/expensive.
2. Question is how to make the change control process less error-prone/expensive?
3. Reverse question is how to make change control process more error-prone/expensive?
4. Reverse solutions include making sure software engineers overwrite each other's work, making sure changes are not tracked, and making sure no mechanism for change request approvals exists.
5. Potential solutions include ensuring engineers don't overwrite each other's work, changes are tracked and a change request approval mechanism based on importance/cost exists.

Problem-Solving Technique: Root Cause Analysis

• Root cause analysis has three steps:
• Clearly define the problem.
• Identify its root causes & resulting effects.
• Correct the root causes of the problem.
• It helps address the real causes of a problem, so don't just treat the symptoms.
• Cause-effect analysis is one type.

Root Cause Analysis example

• Start with cause-effect analysis where problems communicated by users is translated into more clearly articulated problems and their associated causes and effects.
• A user says, “The system is frustrating to use”.
• A software engineer analyzes the frustration which they determine is caused by slow response time attributable to a network bottleneck, not a problem with the software itself.

Problem-Solving Technique: Trial-And-Error

• Trial-and-error means testing possible solutions until the right one is found.
• Design Prototyping:

1. Constructing a first prototype, representing feature and interaction conception.
2. Client/user evaluates the prototype, gives feedback, and suggests changes.
3. Review the prototype and evaluate again.
4. The process ends after the prototype is correct (i.e., the design problem is solved).

System Development Life Cycle (SDLC)

• Process to use when attempting to solve a problem

SDLC definition

• SDLC, from the beginning of lecture, consists of activities/tasks for a project to complete.
• Combination and ordering is not specified.
• S can be for software or system.
• S is for software only if software activities and tasks are involved in creating software artifacts (e.g., database design, construction, and testing).
• S is for system because software projects go beyond hardware acquisition, training, and end-user support.

SDLC Activities

• The four activities match Pólya's approach to problem solving:
• Analysis (understanding of the problem.)
• Design (devising a plan.)
• Implementation (carrying out the plan.)
• Maintenance (looking back.)

Analysis Tasks

• Examine & learn about entity's nature/functions and its parts.
• Break down an entity into fundamental elements, examine those elements carefully, and study how they interact.
• Understand nature of client's/user's problems.
• Typical tasks:
• Problem identification identifies major problems with the system.
• Problem analysis thoroughly understands problems.
• Scope definition agrees on nature/execution of project (dev. & client/user).
• Requirement identification elicits requirements of the proposed system.
• Project estimation predicts required effort and cost to complete software project.
• Decision analysis decides the best way to implement a solution to the client's problem.

Design Tasks

• Design is planning the form/function of something before building and using it.
• Understand the entity by drawing diagrams/charts, creating models and prototypes, describing processes, and identifying patterns.
• Design in SDLC includes the look, feel, and features of solution to client's problem.
• Typical Tasks are:
• Model a database for storing data.
• Plan the data flow through the system, describing features.
• Capture and validate data to prohibit bad data.
• Plan user interface layout for ease of use and look.
• Plan the layout of reports and other outputs.
• Plan functionality / structure of system's components.

Implementation Tasks

• Creating something concrete and put it into use.
• Build/test an entity, prepare its use, and place it into operation for a useful purpose.
• Implementation in SDLC builds and tests the solution to the client's problem.
• Typical tasks include:
• Writing / modifying source code of the system.
• Running the system to validate and confirm requirements, uncover defects, and confirm correctness.
• Transferring data to a new system.
• Installing the system in the client's hardware or software environment, and deploying.
• Transferring the process of the current system to the new system.

Maintenance Tasks

• Maintenance keeps something in good, working condition.
• Fix it when broken, update it, improve it, and modify it to keep it available/useful.
• Maintenance in SDLC ensures the solution to the client's problem works.
• Typical tasks include:
• Corrective maintenance, which isolates and correct errors discovered by users.
• Perfective maintenance, which improves the system's usefulness.
• Adaptive maintenance, which brings the system into compliance with external changes.
• Preventive maintenance, which detects and correct latent errors before users do.
• Refactorative maintenance, which improves code efficiency and ease of maintenance.

Tasks / Deliverables

• Each task produces a tangible deliverable to a client.
• A client can be:
• Internal (e.g., another software engineer or a project manager).
• External (e.g., a client, a process auditing firm, or users).
• Deliverables include:
• Plans, models, diagrams, code, user documentation.
• Others include user training and technical support.