Software Engineering Fundamentals & SDLC

Software Engineering Fundamentals

• Software engineering is an engineering discipline focused on the cost-effective development of large and complex software systems.
• Software engineering involves a systematic approach: Design, Build, and Test.
• Software engineering focuses on real-world goals, services, constraints, precise specification of system structure and behavior, and implementation of these specifications.
• The core activities in the software engineering process are specification, design and implementation, validation, and evolution.

Software Development Lifecycle (SDLC) Models

• SDLC models each have different characteristics and are suitable for different project types.

Waterfall Model

• The waterfall model is a sequential approach where each activity is a separate phase receiving feedback from another phase.
• The waterfall model is best suited when requirements are well-understood and changes will be fairly limited during the design process for example in embedded, critical, and large software systems.
• The distinct phases of the waterfall model are requirements definition, system and software design, implementation and unit testing, integration and system testing, user acceptance testing, operation, and maintenance.
• A characteristic of the waterfall model is downtime.

Incremental Development

• Incremental development involves developing an initial implementation, gathering user feedback, and evolving the software through several versions.
• The incremental model is suitable when requirements are likely to change during development, such as in business systems and software products.
• The incremental model offers advantages of flexibility, easier testing and debugging, rapid delivery, and easier feedback integration.
• Disadvantages of incremental development are the need for good planning, potentially higher total cost, and well-defined module interfaces.

Spiral Model

• The spiral model focuses on risk assessment and minimizing project risk by breaking a project into smaller segments.
• Each cycle in the spiral model involves identifying objectives, risk assessments and reduction, development and validation, and planning.

Agile Methodologies

• Agile methodologies emphasize iterative development, flexibility, and customer collaboration.
• Examples of Agile Methodologies are Scrum, Kanban, Hybrid, Lean, Bimodal and XP
• Scrum uses short development cycles ("sprints") to produce shippable product increments, and emphasizes transparency, inspection, and adaptation.
• Scrum roles, artifacts, and events include:
  • Roles: Product Owner (manages product backlog), Scrum Master (facilitates the process), Development Team (develops the product).
  • Artifacts: Product Backlog (list of features), Sprint Backlog (tasks for a sprint), Product Increment (shippable product).
  • Events: Sprint Planning, Daily Scrum, Sprint Review, Sprint Retrospective.

Requirements Engineering

• Requirements engineering is the process of establishing required services and constraints on the system’s operation and development.
• Requirements engineering activities include requirements elicitation, requirements specification, and requirements validation.
• Requirements elicitation involves discovering and capturing requirements through techniques like interviews, workshops, surveys, prototyping, and use cases.
• Requirements specification involves documenting user and system requirements; user requirements are high-level and user-centric, while system requirements are detailed specifications from a system point of view.

Types of Requirements

• Functional Requirements (FR) describe functionalities or services the system should provide; for example, a user should be able to search appointment lists for all clinics.
• Non-Functional Requirements (NFR) define qualities or attributes of the system, like reliability, performance, security, and usability; for example, the system should load the homepage in under 3 seconds under normal network conditions.

MoSCoW Prioritization

• MoSCoW prioritization is a technique for prioritizing requirements.
  • M: Must have - mandatory requirements that are fundamental to the system (Have).
  • S: Should have – important requirements (Desired).
  • C: Could have – optional requirements​ (Nice to have)
  • W: Won’t have – these requirements really can wait, not priority
• Requirement validation involves checking requirements for validity, consistency, completeness, realism, and verifiability, ensuring that the system meets the user’s needs.

Software Modelling with UML

• The purpose of Software modelling with UML is to develop abstract models of a system from different views or perspectives.
• Software modelling with UML helps analysts understand system functionality and communicate it to customers.
• Benefits of software modelling with UML include overcoming complexity, addressing lack of abstraction, and shifting focus from implementation to design.
• Software modelling with UML hides system complexity by looking at a problem from a certain perspective, focusing on relevant parts and ignoring irrelevant details.
• Views of the model that UML show are external (system context), interaction (how the system interacts), structural (system organisation), and behavioural (dynamic behaviour).

UML Diagrams

• Use Case Diagrams help users understand the system functionality from a user’s perspective, depicting interactions between actors and the system, and include actors (roles), use cases (system functions), and relationships (extend, include, generalization); use cases are named by verb + Noun.
• Activity Diagrams model workflows by identifying steps involved in a process and the conditions that govern the flow of work, and show dependencies and coordination between activities.
• Sequence Diagrams show interactions between objects over time, illustrating the sequence of messages exchanged between objects, and can include interaction frames for conditional behavior (alt, opt, loop): horizontal defines which objects/participants are acting and Vertical represents forward in time.
• Class Diagrams describe the structure of a system by showing classes, attributes, operations (methods), and relationships between classes, and are used to model the static structure of a system; class attributes and operations include public (+), private (-), protected (#), package (~); relationships include association, aggregation (weak "part-of" relationship), composition (strong "part-of" relationship), generalisation (inheritance), and dependency (one class uses another); multiplicity expresses how many objects of each class take part in the relationships (Exactly one - 1, Zero or one - 0..1, Many - 0..* or , One or more - 1.., Exact Number - e.g. 3..4 or 6).

The London Ambulance Service (LAS) Case Study

• The London Ambulance Service case study involved the development of a computer-aided dispatching system with AVLS and MDTs to replace a manual system.
• The London Ambulance Service system failed in October 1992, leading to severe consequences, such as delayed ambulances and patient deaths.
• Causes of the failure included incomplete and untested software, a high-risk implementation approach, inappropriate assumptions during specification, lack of user consultation, and poor fit with the organizational structure.
• The software was incomplete and effectively untested.

Agile Story Example

• Agile story example contains the definition of "ready", acceptance criteria, definition of "done", and outline subtasks.
• An example of an Agile story is: "As a store owner, I want to add items back to inventory when they are returned or exchanged, so that I can sell them again."
• Acceptance Criteria (BDD) will follow a Given (initial context), When (event), Then (expected outcome) methodology.

Key Takeaways

• Understanding and managing risks is crucial for software project success.
• The SDLC model you choose depends on project characteristics.
• Requirements engineering is a critical process that should involve stakeholders.
• UML modelling aids in communication and design.
• Ignoring user needs and proper testing can lead to disastrous outcomes (LAS case).
• Clear and unambiguous requirements are essential for successful software development; use "shall" for requirements and "should" for recommendations.