The Waterfall Model: SEQUENCE Requirements Analysis and definition System and software design Implementation and unit testing Integration and system testing Operation and maintenance

EXAMPLES: Embedded systems Critical Systems Large software systems Safety systems

Incremental Development (Agile): INTERLEAVED Specification Development INTERLEAVED Validation

ADVANTAGES: Cost Reduction Quick Customer Feedback Early Delivery

DISADVANTAGES: Process not visible Systems tend to degrade

Reuse Integration and Configuration: STAND ALONE

EXAMPLES: Stand alone Collection of objects WEB services

Requirements Discovery & Evaluation Requirements refinement Application System Config Component Adaption

1. SOFTWARE SPECIFICATION:

- Feasibility Study- Elicitation and analysis- Requirements spec- Requirements validation

2. SOFTWARE DESIGN AND IMPLEMENTATION

- Architecture Design- Database Design- Interface Design- Component Selection & Design

3. SOFTWARE VALIDATION

- Component Testing- System Testing - Customer Testing

4. SOFTWARE EVOLUTION

-

PROTOTYPING:

Coping with Change

CHAPTER 2: DIFFERENT PROCESSES

CHAPTER 3: INCREMENTAL DEVELOPMENT PROCESS

AGILE PRINCIPLES:

1. Customer Involvement2. Embrace Change3. Incremental Delivery4. Maintain Simplicity5. People, not process

Examples:

Extreme Programming User Stories Refactoring Test-first development Pair programming Scrum Scaling

Problems:

Informal Approach – Incompatible with legal New Software Small, co-located teams

1. Differences between plan-driven and agile development: Plan Driven approach:

i. Based around separate development stages with outputs to be produced at each stage planned in advance

ii. Not necessarily waterfall model. Possibly plan-driven, incremental development.

iii. Iteration occurs within activities Agile Developments

i. Specification, design, implementation and testing are inter-leaved and the outputs from the development process are decided through a process of negotiation during the software development process.

Agile for Large Systems:

1. Large systems are usually systems of systems2. Large systems are brownfield systems3. Where several systems are integrated to create a system4. Large systems and their development processes are often

constrained by external rules and regulations5. Large systems have a long procurement and development time6. Large systems usually have a diverse set of stakeholders with

different perspectives and objectives.

CHAPTER 4: REQUIREMENTS

BUSINESS DRIVES CHANGE AND REQUIREMENTS

Requirements:

Functional: What the system must do. Non-Functional: Constraints, such as time, process, speed, ease of use, size, reliability, Robustness, portability, availability

User: Functional Requirements written in plain language System: Non-Functional, more details and possibly used as a contract

Requirements Engineering:

Elicitation Stories & Scenarios Specification:

o Natural Languageo Structural Languageo Mathematicalo Notations

Use Case Requirements document Requirements Validation

CHAPTER 5: REQUIREMENTS VALIDATION

Context Models:

Activity Diagram (UML)

Interaction Models:

Use Case

Sequence Diagram

Structural Models:

Class Diagrams

Generalisation

Aggregation

Behavioural Models:

Data Driven Models

Event Driven Models

Model driven engineering

CHAPTER 6: ARCHITECTURAL DESIGN

Architectural Design: Small: Applications Large: Enterprise

Architectural views:

Logical View Physical View Development View Process View

Patterns:

Layered Repository Client Server Process View

Application:

Transaction Information Language

Decision:

Performance Security Safety Availability Maintainability Resilience Reliability Speed Size (Volume) Robustness Portability

CHAPTER 7: INTERFACE DESIGN

Design & Implementation: System context

Use Case

Architecture Design

Client Server Design Models

o Static: Important relationships that may be documented at this stage are generalization (inheritance) relationships, uses/used-by relationships, and composition relationships.

o Dynamic: show the expected runtime interactions between the system objects.

Sequence Diagram

State Diagram

Interface Design

UML

Implementation and configuration

Re-use Management

Open Source Development

CHAPTER 8: TEST SOFTWARE

Software Testing:Ensures what the program is intended to do, that meets the requirements (Validation), and built correction, fit for use (Verification)

1. Development Testing:a. Unit testing

i. Individual Function methods or object classesb. Component Testing

i. Test interacting objectsii. Stored objects

c. System Testingi. Test the integration of components

2. Release Testing: Testing a particular release of the system, Dedicated Team

a. Requirements based testingb. Scenario Testingc. Performance Testing

3. User Testing: User / Customer Testing either informally / formallya. Alpha Testing b. Beta Testingc. Acceptance Testing

i. Define Acceptance Criteriaii. Plan Acceptance Testing

iii. Derive Acceptance Testingiv. Run Acceptance Testingv. Negotiate test Results

vi. Reject / Accept Systems

4. TDD: Test Driven Developmenta. Identify taskb. Write the testc. Run the testd. Implement, re-run teste. Once everything passed, move along

CHAPTER 9: DEPLOY AND MAINTAIN

Software Evaluation:

Long Shelf life to get ROI Correct Errors Adapt to Hardware / Software Improve Performance Evolve with business

Process:

1. Change Identification process2. Change proposals3. Software evaluation process4. New System, and repeat

Urgent Changes:

1. Serious Faults2. Unexpected system operation that disrupts company operations3. Unanticipated changes, new legislations or competitor

Agile – Plan – based docsPlan Based – Agile Test Cases

Legacy Systems:

Older Systems relying on outdated technology and languages Structure degradation over time Dependent on old hardware / vendors

Difficulty to replace Legacy

No complete specification Intricate business process Embedded business rules New Software – Risky

Strategy: Compare business value with system quality

1. Scrap Completely2. Leave unchanged, continue with maintenance3. Re-engineer for improvements4. Replace all or parts of system

Software Maintenance: Changing of software after it has been delivered

More Expensive to add Features:

New team to understand Development team have no liability for support Free maintenance work is unpopular As they age, harder to change

Business is reluctance:

Money / cost Dev sees it as pointless

Software Re-engineering:

Reduced Risk & cost

Refactoring:

Making Improvements:o Duplicate codeo Long methodso Switch statementso Data clumping

3 Types of Software Maintenance: CAP

Corrective: Fault repairs to fix bugs and vulnerabilities Adaptive: Environment adaption, new software or environment Perfective: Functionality Addition

No Clear-cut distinction between these, when a system is adapted to a new environment, some new functionality may be added to take advantage of new features. Software faults are exposed because users use the system in an unanticipated way

Source Code Translation:o Using a translation too, program language can be converted

from the old programming language to a new one. Reverse Engineering:

o Program is analysed and its organisation and functionality is documented.

Program Structure improvement:o Structure is analysed and modified to make it easier to read

and understand. Program modularisation:

o Related parts of the program are grouped together. Redundant parts are removed.

Data Re-engineering:o Data processing of the program is changed.

CHAPTER 10: DEPENDABLE SYSTEMS

Principal Dimensions:

1. Availability2. Reliability3. Safety4. Security5. Resilience

Related properties:

1. Repairability2. Maintainability3. Error Tolerance

Sociotechnical Systems:

Emergent Propertieso Properties of the system as a whole that depend on system

components and their relationships, that are only assessed and measured once components are integrated.

Nondeterministic properties:o Not always producing the same output when presented the

same input due to the difference behaviour of human operators.

Complex Systems:o System components are dependent on other system

components.

CHAPTER 11: RELIABILITY ENGINEERING

Functional Reliability Specification:o Checking Requirements:

Ensuring correct inputo Recovery Requirements:

Assists the system recover from a failureo Redundancy Requirements:

Specify redundant features of the system ensuring a single component failure doesn’t lead to loss of service

o Process Requirements: Fault avoidance requirements

CHAPTER 12: SAFETY ENGINEERING

Operating without catastrophic failure

Safety-critical Systems:

Primary: o Software embedded as a controller in a system.o Malfunction of software can cause hardware malfunction.o E.g. Insulin Pump

Secondary:o Software malfunction that can indirectly result in an injury

Hazard Driven Techniques for Fault avoidance, detection, and removal:

1. Avoidance: Designed so hazards are avoided – Foot on clutch to start a car

2. Hazard Detection and removal: Hazard detection and removal before resultant damage – Pressure relief valve

3. Damage limitation: Protection to reduce damage from accident – Automatic fire extinguisher on aircraft engine.

CHAPTER 15: SOFTWARE REUSE

Examples of reusable software units:

System reuse: Reuse of entire systems for system of systems Application reuse: Used without change and incorporated into

other systems Component Reuse: Components of an application may be reused. Object and function reuse: Reuse of a single function of object

class.

Software product lines can be adapted to suit specific business operations. Such as an accounting package being adapted to suit a business dealing with multiple foreign currencies.

CHAPTER 18: SERVICE-ORIENTED SOFTWARE ENGINEERING

Service-oriented architecture is an approach to software engineering where reusable, standardized services are the basic building blocks for application systems.

The service engineering process involves identifying candidate services for implementation, defining the service interface, and implementing, testing, and deploying the service.

Web Services:o Run in a browser and operate the same way regardless of

operating environment.o Always up to date.o Follows Standards and XML based messageso Example: Sage One accounting or Aircraft Manuals online

RESTful serviceso Not exclusively XML basedo Representations get transferred from a server to a client.o Services should be stateless

CHAPTER 19: SYSTEMS ENGINEERING

Sociotechnical systems:

Include Hardware, software, and now people, processes, and organisational policies.

System development:

Complex process in which elements part of the system are developed or purchased and then integrated to create a final system.

System requirements are the bridge between conceptual design and development process.

7 Fundamental development activities:o Requirements engineeringo Architectural designo Requirements partitioningo Subsystem engineeringo System integrationo System testingo System deployment