Upload
others
View
7
Download
0
Embed Size (px)
Citation preview
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