Software Engineering and Information Systems Development Introduction

Fundamentals of Software Engineering

  • Software Engineering and Information Systems Development (CSE 403) Lecture 1 provides an introduction to the core principles of building quality software.
  • A large software project is managed through the following strategies:
    • Breaking the project up into smaller, manageable sub-problems.
    • Solving each sub-problem independently.
    • Operating within teams.
    • Maintaining consistency across the project.
    • Ensuring the process is cost-effective.
    • Designing the system to be easy to change or modify.

The Motivation Behind Building Software

  • Software is primarily built to assist business clients or users in solving specific problems, frequently referred to as "pain points."
  • Key questions to identify pain points:
    • What is currently not working properly?
    • What is causing distress or difficulty for the user?
    • How serious is the identified pain?
  • Example: A business may be unable to respond quickly to changing market conditions, representing a high-level pain point.
  • Client Insight Limitation: Clients and users are generally adept at expressing their pain points but are often unable to define the technical solution.
  • Human-Centric Motivation: Software also addresses social or psychological needs, such as "I am bored" or "I need inspiration." Many entertainment or creative systems are built to address these specific human conditions.

Problem Definition and Context

  • Software addresses both "pain points" and "pleasure points."
  • The likelihood of project success is directly proportional to how well the problem is stated or framed.
  • Success requires proper attention to details regarding what is malfunctioning or hurting the user.
  • Analysis Process:
    • Identify high-level pain/pleasure points.
    • Perform further detailed analysis to gain a comprehensive view of the problem.
  • Contextual Awareness: Problems do not exist in isolation; they exist within a context. Understanding the context is mandatory for understanding the specific nuances of the pain points.
  • Domain Vocabulary: Understanding the problem context requires mastery of terminology specific to the problem space.
    • Examples: In the banking domain, terms like "Credit," "Debit," "Account," and "Statement" have specific functional meanings.
  • Activities and Processes: It is necessary to understand the tasks that require software solutions, such as the "Enrolment" process in an academic context.

Actors and Goals

  • Actors: In Software Engineering, people or things that interact with the software being developed are called "Actors."
    • Actors can have significant impacts on how the software should operate.
    • Analyzing these impacts is critical for ensuring client pain points are addressed.
  • Roles vs. Individuals: A single human can take on multiple roles within a system.
  • Non-Human Actors: External systems that interface with the software are also considered actors.
    • Example: An iPod acts as an actor within the iTunes system.
    • While the iPod is non-sentient, its "pain points" represent the interface requirements defined by its developers who want a simple interface to the iTunes software.
  • Actor Goals: Every actor has a set of pain/pleasure points and a desired "GOAL" state.
    • Software must enable the actor to transition from their current state to their goal state.
    • Example Goals:
      • Retrieve a list of the latest books on Object-Oriented Analysis and Design (OOAD).
      • Purchase a book from an online storefront.
      • View the latest video lectures on OOAD.

Project Constraints and Assumptions

  • Constraints: These factors restrict the choices available for solving a problem. Examples include:
    • Time and Budget: Solving a problem within 2 months with a budget of XX.
    • Legacy Technology: Improving the performance of an existing system written in COBOL.
    • Deployment Environment: Ensuring a system works in a specific environment, such as Linux.
    • External Factors: Laws, regulations, and the current training or education level of the end-users.
  • Assumptions: These are beliefs held about the problem domain during development that should be verified for validity.
    • Example: Assuming all users understand English and writing instructions accordingly.
    • Invalid assumptions can lead to the development of useless solutions.
  • Analysis of the Problem Domain includes:
    • Identifying actors.
    • Understanding each actor's needs and impacts.
    • Formulating the goals of each actor.
    • Identifying constraints.
    • Defining the domain vocabulary.
    • Determining the "solution direction."

Solution Development and Refinement

  • Decision Making: Developing a solution involves choosing the best option from various potential solutions. This process is influenced by:
    • Constraints and environmental factors.
    • The habits and personality of the developers/decision-makers.
  • Evaluating Choices: Developers must ask if choices are reasonable, defensible, and what impact they will have on subsequent steps.
  • Solution Domain Evolution:
    • Starts with a general solution direction.
    • Refined throughout the development process based on a deeper understanding of the problem domain and previous decisions.
    • Note: Past decisions often restrict the scope of future actions.
  • Domain Differentiation:
    • Problem Domain: Focused on Analysis and Requirements to understand the problem.
    • Solution Domain: Focused on Design and Implementation to find and build the solution.

Program Statements

  • In the early stages of development, two specific statements should be created: the Problem Statement and the Vision Statement.
  • Problem Statement:
    • Describes what needs to be done without detailing how.
    • Must be agreed upon by all project members.
    • Facilitates communication between technical and non-technical personnel.
    • Example: Identifying that elderly individuals with speech, hearing, or memory disabilities face difficulty communicating and seeking emergency help, and stating that a mobile app for expression and emergency contact would be a successful solution.
  • Vision Statement:
    • Captures the essence of the system and serves as a marketing tool.
    • Keeps the development team focused on the "core" mission.
    • Template structure:
      • For: (target user/audience).
      • Who: (statement of need or opportunity).
      • The: (product name) is a (product category).
      • That: (key benefit or compelling reason).
      • Unlike: (primary competitive alternative).
      • Our product: (statement of primary differentiation).
  • Example Vision Statement (HOPE Cellular Phone Application): For elderly or disabled persons with communication difficulties, the HCPA is a software application that provides effective communication and swift emergency contact through an intuitive interface, unlike existing systems with poor interfaces, by using text-to-speech and speech-to-text functionality.
  • Example Vision Statement (CSE_Dynamics Game): "CSE_Dynamics is the real-time strategy game for CSE, JU students who are bored in between classes. Unlike Warcraft, CSE_Dynamics is custom designed to ensure hours of interactive game play between CSE, JU students."
  • Example Vision Statement (MJB Online Job-board): "The MJB is an online job board for candidates who are seeking jobs. Unlike the classified section of the newspaper, MJB allows recruiters to post vacancies and allows job hunters to fast search and real-time access to positions."

Gap Analysis and Spiking

  • Gaps represent risks that can cause project failure. There are three primary types:
    • Knowledge Gap: Incomplete understanding of an issue or aspect. Often caused by over-confidence or ego hiding issues.
    • Skill Gap: Understanding a task but lacking the practice to perform it effectively (e.g., being unable to estimate how long a task will take).
    • Technology Gap: Knowing what to do but not knowing which technique or technology to use, or if the technology is affordable.
  • Mitigation Strategy:
    • Gap analysis is required to determine the criticality of gaps.
    • "Spiking" is the process of creating a plan to close these gaps early.
    • Without early spiking, the probability of project failure increases.
  • Capturing Gaps: As development progresses, new questions arise regarding libraries, frameworks, and quality goals. Identifying which gap motivates these questions helps define the spiking plan.

Case Study: Weather Forecast Project

  • Problem Description: Jerry lives in Melbourne and is frustrated by odd weather patterns because he frequently wears inappropriate clothing or gets wet while walking to work.
  • Analysis:
    • Actor: Jerry.
    • Pain Points: Frustration with weather unpredictability; getting wet because of lack of preparation.
    • Goal: Jerry needs the latest reliable weather forecast before getting dressed and leaving home.
  • Technical Problems to Solve:
    • Presenting data in a way Jerry can act on.
    • Selecting a provider with at least 95%95\% accuracy for the next day.
    • Defining a retrieval mechanism and frequency (Hourly vs. Daily vs. Weekly), which affects reliability and cost.
  • Identified Knowledge Gaps:
    • Defining what constitutes "latest" weather.
    • Establishing metrics for reliability/accuracy.
    • Determining the cost/impact of providing wrong information.
    • Determining how much data Jerry needs to dress properly.
    • Deciding if Jerry needs training in meteorology vocabulary.
    • Choosing a delivery medium (SMS, Email, etc.).
  • Potential Solutions:
    • 1. Change the weather in Melbourne.
    • 2. Brainwash Jerry to accept the weather.
    • 3. Provide a latest forecast before he leaves home (Chosen).
    • 4. Teach Jerry to wear layers.
  • Assumptions for Chosen Solution:
    • Jerry reads English and basic weather terms.
    • A weather source exists (infrastructure is already built).
    • Jerry will make wise choices if given accurate data.
    • Jerry has a device to receive SMS/Email and can register via the Internet.
    • A reliable provider exists at a "reasonable price," defined as less than 5c5\text{c} per day.
  • Solution Attributes:
    • Mediums: SMS/Email, Internet, Secure (encrypted user data).
    • Content Characteristics: Accurate/Reliable (95%95\% correct), Current (2424-hour period), Simple and Clear (common language).
  • Refined Decisions:
    • Data Source: Bureau of Meteorology (BOM) free website data.
    • Delivery: SMS message at 6:00am6:00\text{am} based on the 5:00am5:00\text{am} BOM forecast.
  • Domain Vocabulary: BOM, Weather forecast, Rain, Showers, Fine, Registered user.
  • Data Analysis for Implementation:
    • Measurement units: Celsius vs. Fahrenheit.
    • Input/Output: Temperature range, current temperature, wind speed, and probability of rain.
    • Sample Output: "Rain in the morning. Fine after. 12∘C−24∘C12^\circ\text{C}-24^\circ\text{C}. Current temp: 12∘C12^\circ\text{C}, Wind: 5 miles/hr5\text{ miles/hr} north."
    • Constraint check: How to fit data into one SMS; risks of BOM stopping free services; handling Jerry moving to a different city.