401 lecture 2

• This lecture provides an introduction to Software Architecture for SENG 401. It is presented by Dr Ronnie de Souza Santos.

Software Crisis

• This was a period when the software industry faced significant challenges in creating and maintaining software systems.
• This crisis occurred in history of Software Development.
• During this period, software development was difficult, inefficient, often resulted in overtime, and frequently exceeded budgets
• The Software Engineering discipline came out of this period (1960-1970)

Software Development

• This is a systematic process that outlines the phases that a software project goes through from initiation to completion and maintenance.
• This process should be structured and based on quality communication
• Software development includes management of the project, resources and tasks
• The motivation of the development methodology is to produce software that meets or exceeds customer's expectations

Software Development Core Tasks

• Include Analysis, Design, Construction, Testing and Delivery.
• Also includes Management of costs, people, resources and time

Software Architecture

• This defines the high-level structure of a software system
• It defines components and their interactions
• It sets the foundation for the design and implementation phases of software development
• Analysis focuses on "what" is the problem
• Design focuses on "how" to fix the problem

The Role of Software Architecture

• Architecture decisions have a large effect on the long-term cost and quality of a system
• Software architecture can influence the ease of future modifications
• It aids in managing complexity, especially in large systems
• The planning and design ensures different parts of the program work together and function well

Reference Architecture

• This is the set of principal decisions that are simultaneously applicable to multiple related systems
• Reference architecture is typically within an application domain
• It provides explicit definitions of points of variation
• In addition, it provides standardized guidelines and proven solutions for efficient, consistent and reliable system architectures

Design Decisions

• Design decisions are choices that are made during the creation or planning phase of a system
• Kinds of decisions to be made include what approaches, methods, technologies and configurations to use
• Also includes structure, behavior and interaction

Principal and Temporal Design Decisions

• Principal decisions are critical or fundamental choices that influences the overall architecture, functionality, or behavior of a system
• Technologies and Data are Principal
• Temporal decisions include the choices made or unmade and involve aspects related to periods within the system
• Interface is Temporal

Banking App Design Decisions

• The Operating System, Biometrics and Cloud are Principal
• Push notifications, engaging users, and optimization are Temporal

Stakeholders

• These are individuals or groups interested in, or impacted by, the development, deployment or utilization of a software system architecture and design
• Includes architects, developers, testers, managers, clients and users

Software Engineering

• Margaret Hamilton coined the term "Software Engineering" in the 1960s.
• She led NASA's team that developed the Apollo Mission's flight software.
• She introduced the term to emphasize the rigorous, systematic approach that was needed for software development which was then viewed as less formal than hardware engineering

Requirements Engineering

• This is the process of gathering, documenting, analyzing, prioritizing, validating, and managing requirements throughout the project lifecycle
• The stakeholders needs are central
• There is motivation to ensure project delivers desired outcomes while reducing risks
• Includes Change Management

Care About Requirements

• Defining Requirements involves considering the What, the How, the Who, and the Costs Vs Time

Types of Requirements

• Software requirements define what a software system should accomplish and how it should behave
• It provides the basis for designing, building, and testing software solutions
• It can then be categorized as Functional, Non-Functional and Domain specific

Basic Requirements

• Functional requirements focus on the specific Tasks and Functionalities that the software system must perform
• Non-Functional requirements describe the behaviors and characteristics that the software must possess

Non-Functional Requirements Examples

• Performance specifies how quickly the system should respond or process tasks (e.g. system should process 1,000 transactions per second)
• Scalability defines the system's ability to handle increasing loads without performance degradation (e.g. system should handle 10,000 concurrent users without degradation)
• Usability focuses on the system's ease of use and learning curve for end users (e.g. user interface should be intuitive and require minimal training)
• Security ensures system is protected from unauthorized access or attacks (e.g. all data encrypted using AES-256 encryption)
• Reliability specifies the system's ability to perform consistently under expected conditions (e.g. system should have 99.9% uptime)
• Availability indicates how often system should be available for use without downtime (e.g. system should be available 24/7 no more than 1 hour of downtime per year)
• Maintainability describes the ease which system can be modified or updated (e.g. system should be able to update features without downtime)
• Portability ensures system can be easily moved or adapted to different environments (e.g. system should run on both Windows and Linux platforms)
• Accessibility focuses on system usability for people with disabilities (e.g. websites should support screen readers for visually impaired users)
• Compliance ensures system complies with laws and regulations (e.g. GDPR) (e.g. system must comply with the GDPR for data protection)
• Interoperability describes how system interacts with other systems or components (e.g. system should integrate with third-party payment gateways)
• Ethics ensures the system adhere to ethical standards (e.g. system ensures fairness in route suggestions without bias)

Requirements Examples in a Message App

• Functional: Create a profile, Login into the system, add a photo to the profile, send message to contact, delete profile
• Non-Functional: New Profile is confirmed via SMS, Login required Email/Password for Validations, Photo is up to 2GB, message is 250 characters long, deleting profile is confirmed via a call

Requirements Specification

• User Stories: Short, simple descriptions of a feature, told from the perspective of the person who will use it
• Use Cases: A methodology, clarify and organize system requirements, used in system analysis to identify

User Stories

• These are informal, natural language descriptions of features of the software
• They are written by or for users or customers
• They influence the functionality of the system being developed
• Follows a format : As a (type of user), I want (some goal) so that (some reason)

Use Cases

• This documents the user interface with the system in actions / events
• Use cases use UML (Unified Modeling Language)

Good Requirements

• Unambiguous
• Complete
• Coherent
• Verifiable
• Feasible
• Prioritizable
• Validatable

Requirements prioritization

• Mo: These are non-negotiable, the minimum viable product, unable to deliver the end product without this, not legal without it, unsafe without it, and without this project is not viable
• S: These are importunate, but not vital May be painful to leave out But solution is still viable. May need to implement a workaround
• Co: Desirable but not essential, to have extra time and budget, important after should have.
• W: Will not be able to implement at all, Out of budget, if no real impact.

Examples of Functional Vs Non-Functional Requirements

• Functional: The app should allow users to search for products by name, category or keywords
• Non-Functional: The app should load product pages in under 3 seconds, even during peak traffic times
• Functional: Users should be able to register and log in using their email or social media accounts
• Functional: The app must support multiple languages for global users
• Functional: Users should have the ability to add terms to a shopping cart and update quantities
• Non-Functional: The app must be available on both iOS and Android Platforms
• Non-Functional: The user interface should be intuitive, requiring no more than 3 clicks to complete a purchase
• Functional: The app must provide real-time order tracking after purchase
• Non-Functional: All user data, including payment information, should be encrypted using industry-standard methods
• Non-Functional: The system should have automatic daily backups, recover data within 30 minutes
• Functional: Users should be able to create wish lists for future purchases
• Non-Functional: The App to be optimised for mobile devices responsive to display on all screen sizes
• Functional: The app should support users submitting requests for eligible items through a return or refund
• Non-Functional: App Comply with Data Privacy Regulations
• Functional: Admins can manage product inventory an receive alerts for low stock products an be able
• Non-Functional: Supp screen readers and have high contrast mode for visually impaired users
• Non-Functional: Push notifications alerting users to new product or sale announcements discount / updates
• Non-Functional: Support App load up to 100,000 concurrent users during major sales events