COSC 4P01: Lecture 2 and 3 Notes

Todo

Catch up on week 1 slides. Beyond here is starting in week 2 (but using week 1 slides)

Agile Project Management

Traditional

• Plan driven
• Cost structure known ahead of time (usually)
• Time known ahead of time (approximately)

Scrum

Scrum Term	Definition
Development team	A self-organizing group of software developers, which should hbe no more than seven people (ideally 4 people). They are responsible for developing the software and other essential project documents.
Potentially shippable product increment	The software increment that is delivered from a sprint. The idea is that this should be “potentially shippable” (not always achieveable).
Product backlog	A to-do list that the scrum team must tackle. E.g. github issues, JIRA board
Product owner	An individual or small group of people whos job is to identify necessary product features or requirements and ensure the project is on track.
Scrum	Standup meeting. What have you done, what are you currently doing, what are you going to do.
Scrum Master	Essentially the manager. The person that is responsible for ensuring that the Scrum process is followed and guides the team in the effective use of Scrum. They are responsible for interfacing with the rest of the company and ensuring the Scrum team is not diverted by outside interference.
Sprint	A development iteration. Usually 2 or 4 weeks.
Velocity	An estimate of how much product backlog effort a team can cover in a single sprint. Used to better understand what amount of work can be covered in a sprint. A team performance metric.

Requirements document

• Decided and developed during the start of each sprint
• Things that are unstable at the end of a sprint are placed in the backlog
• Every member of the team has a good idea of what everyone else is working on (team visibility)
• Trust between customers & developers

Sprint review

Determines:

• backlog
• release product

Distributed Scrum

• Scrum master should be located with the development team so that they are aware of everyday problems
• Product owner should visit the developers and try to establish a good relationship with them
• Videoconferencing between the product owner and the development team
• A common development environment for all teams
• Continuous integration, so that all team members can be aware of the state of the product at any time
• Real-time communications between team members for informal communication, particularly instant messaging and video calls

Agile principles and organizational practice

Principle	Practice (simplified)
Customer involvement	Customers need to work closely with the team, but they’re often too busy or limited.
Embrace change	It’s hard to handle changes when many people want different priorities.
Incremental delivery	Short development cycles don’t always match with long-term business or marketing plans.
Maintain simplicity	Teams may skip simplifying the system because of tight deadlines.
People, not process	Agile works best if team members have the right personalities and can collaborate well.

graph TD
    A[System] --> B[Type]
    A --> C[Lifetime]
    B --> D[Scale]
    C --> E[Regulation]

graph TD
    A[Team] --> B[Technology]
    A --> C[Distribution]
    A --> D[Competence]

graph TD
    A[Organization] --> B[Contracts]
    A --> C[Delivery]
    A --> D[Culture]

System issues

• How large is the system being developed?
  • Agile methods are most effective with a relatively small co-located team who can communicate informally
  • E.g. large scale plane software/train management software
• What type of system is being developed?
  • Systems that require a lot of analysis before implementation need a fairly detailed design to carry out this analysis
• What is the expected system lifetime?
  • Long-lifetime systems require documentation to communicate the intentions of the system developers to the support team
  • E.g. Brock still has services using COBOL
• Is the system subject to external regulation?
  • If a system is regulated you will probably be required to produce detailed documentation as a part of the system safety case
  • E.g. financial software has to abide by regulations
• How good are the designers and programmers in the development team?
  • It is sometimes argued that agile methods require higher skill levels than plan-based approaches in which programmers simply translate a detailed design into code
• How is the development team organized?
  • Design documents may be required if the team is distributed
• What support technologies are available?
  • IDE support for visualization and program analysis is essential if design documentation is not available
  • git

Organizational issues

• Traditional engineering = plan-based development → norm in engineering
• Organizations expect detailed system specifications
• Customer reps needed for feedback on increments
• Agile challenge: fitting informal, flexible style into culture of heavy documentation

Agile methods for large systems

• Large systems = collections of smaller systems → each built by separate teams (often in different locations/time zones)
• Many are brownfield systems → must integrate with existing systems, making flexibility/incremental dev harder
  • Brownfield development/systems = middleware
• Integration work = mostly system configuration, not new code development

Large system development

• Large systems face rules/regulations that limit how they can be developed
  • E.g. flight control system
• They have long procurement & dev cycles → hard to keep the same knowledgeable team (people leave/move)
• Large systems involve a diverse set of stakeholders → impossible to include everyone in the process

IBM’s Agility at Scale model

Scaling up to large systems

• A completely incremental approach to requirements engineering is impossible
• There cannot be a single product owner or customer representative
• For large systems development, it is not possible to focus only on the code of the system
• Cross-team communication mechanisms have to be designed and used
• Continuous integration is practically impossible. However, it is essential to maintain frequent system builds and regular releases of the system

Agile methods across organizations

• Project managers without agile experience may resist adopting it.
• Large orgs = strict quality procedures & bureaucracy → clash with agile.
• Agile works best with skilled teams, but large orgs = wide variation in skills.
• Cultural resistance common in orgs with strong traditional engineering history.
• Engineers are trained to be thorough, not necessarily agile/flexible.

Info

End of week 1 slides, start of week 2 slides

Requirement Engineering

Purpose

• Define a description of the needs for the required system

Functional

• What will the system provide to the end user?
• Statements of service
• Users will use the system to achieve their goals
  • How does the system fulfil this goal?
  • What types of data are we dealing with?
  • Organization will receive a benefit

Non-functional

What are the constraints of the system?

• What hardware is available?
• What other systems will interface with this system?
• Response time
• External regulatory constraints
  • Security of data
  • Regulatory certification

Non-functional requirements should be:

• more critical
• broad range
  • security
  • integration
  • redundancy
• should be specified quantitatively (subjectiveness is very hard to measure)

Types of nonfunctional requirements

graph TD
    A[Non-functional requirements]
    
    A --> B[Product requirements]
    A --> C[Organizational requirements]
    A --> D[External requirements]
    
     Security requirements links
    B3 --> B3a[Environmental requirements]
    B3 --> B3b[Operational requirements]
    B3 --> B3c[Development requirements]
    
     External requirements
    D --> D1[Legislative requirements]
    D1 --> D1a[Accounting requirements]
    D1 --> D1b[Safety/Security requirements]

Readers of different types of requirements specification

• End users will have to be explained using different terminology (less technical, etc.)
  • Focus on features, “selling the product”
  • Users are people & are more interested in task completion
• Technical users or developers will be explained using more in depth info etc.
  • Programmers need more detail, require unambiguous descriptions

Need for requirements

We need to determine what the system will ultimately look like.

• Required to define a contract (not just a financial doc, also is a list of requirements)
• Must be specific (cannot say ”… until I am satisfied” → owner can never be satisfied → contract is never completed)

Spiral view of the requirements engineering process

Requirements engineering process

• we want effort early on to understand the system that will be created
• is the feasibility valid?
  • cost? (low end & high end)
  • time? (low end & high end)
• will it integrate with existing systems?
• effort must be made talking to users (usually on the functional side → user requirements)
• result is a rough prototype of what the system will look like and do from a user perspective

System requirements

• constraints must be defined
• these can cause user requirements to be revealed
  • e.g. system requires a login → users required to login

Requirement elicitation

• talk to users, engineers, and stakeholders goal is to extract information:
  • system
  • functional
• these requirements are put together to define a requirements document for the project
• iteration is important

flowchart LR
    A[Elicit Information] --> B[Design Requirement Doc]
    B --> C[Review]
    C --> A

Passive observation

• see what users do, how they react, what they need
• embed yourself into the work environment
• define practical requirements

Stories and scenarios

• user stories: define practical applications of the system
  • may define the scope of the system
  • prototyping can be used extensively to ensure user requirements and expectations are met

flowchart TD
    A[user login] -->|good| B[access]
    A -->|bad| A

Requirement specification

• user requirements have to be easy to understand for end-users and customers who don’t have a technical background
• system requirements are more detailed & contain more technical information
  • meant for developers & engineers
  • unambiguous language → must be very detailed

Notation	Description
Natural language	- requirements written in plain sentences - each sentence = one requirement
Structured natural language	- requirements written in natural language but using a standard template
Design description languages	- uses a programming-like language to specify system models - rarely used now
Graphical notations	- diagrams (e.g., UML) with text annotations to define system requirements
Mathematical specifications	- based on math (e.g., finite-state machines) - precise but hard for customers to understand

Structured specification example

Section	Content
Function	Compute insulin dose: safe sugar level.
Description	Computes the dose of insulin to be delivered when the current measured sugar level is in the safe zone between 3 and 7 units.
Inputs	Current sugar reading (r2); the previous two readings (r0 and r1).
Source	Current sugar reading from sensor. Other readings from memory.
Outputs	CompDose — the dose in insulin to be delivered.
Destination	Main control loop.

Use cases

• identifies the actors in an interaction and describe the interaction itself
• a set of use cases should describe all possible interactions with the system

flowchart LR
    MR[Medical receptionist] --> RP[Register patient]
    MR --> VPI[View personal info]

    N[Nurse] --> VR[View record]
    N --> ER[Edit record]

    M[Manager] --> ES[Export statistics]
    M --> GR[Generate report]
    M --> VPI

    D[Doctor] --> VR
    D --> ER
    D --> SC[Setup consultation]
    D --> GR

Structure of a requirements document

Chapter	Description
Preface	Defines the expected readership. Describes version history, rationale for new versions, and a summary of changes.
Introduction	Describes the need for the system. Briefly explains functions, interactions with other systems, and how it fits into business goals.
Glossary	Defines technical terms used in the document. Avoids assumptions about reader expertise.
User requirements definition	Describes the services provided for the user. Includes functional and nonfunctional requirements in natural language, diagrams, or other notations. Specifies required product/process standards.
System architecture	Provides a high-level overview of the anticipated architecture, showing functions across modules and reused components.
System requirements specification	Describes functional and nonfunctional requirements in detail. Adds further detail if necessary and defines interfaces with other systems.
System models	Includes graphical models showing relationships between system components and environment (e.g., object, data-flow, semantic data models).
System evolution	Describes fundamental assumptions and anticipated changes (hardware, user needs, etc.). Helps avoid design decisions that limit future changes.
Appendices	Provides detailed information related to the application (e.g., hardware, database requirements). Defines minimal/optimal configurations and relationships between data.
Index	Contains indexes (alphabetical, diagrams, functions, etc.) to help navigate the document.