83
Learning Unit 1: Chapter 2 & 3 Objectives: 1. Explain the fundamental concepts of software processes Software is a product designed and built by software engineers. A set of related activities that leads to production of a software product Multiple processes, but four activities that’re fundamental to Software engineering: i. Specification: Defining what the system should do ii. Design and implementation: Defining the organisation of the system and implementing the system. iii. Validation: Checking the system performs in accordance with customer needs iv. Evolution: Changing the system in response to changing customer needs Process model: Abstract representations of a process, essentially the activities that are part of these processes. Example: i. Products: Outcomes of a process activity ii. Roles: Responsibilities of people involved in the process iii. Pre- and post-conditions: Statements that are true before and after a process activity has been enacted. 2. Describe the three generic software processes Not definitive descriptions of software processes, they are abstractions of the process used to explain different approaches to software development. The waterfall model: i. Plan-driven model: Separate and distinct phases of specification and development Incremental development: i. Specification, development, and validation are interleaved – may be plan-driven or agile. Reuse-oriented software engineering: i. System assembled from existing components, may be plan-driven or agile. Most large systems use elements from all these models when in development.

gimmenotes.co.za  · Web viewNot necessarily waterfall model. Possibly plan-driven, incremental development. Iteration occurs within activities. Agile Developments. Specification,

  • Upload
    dangnga

  • View
    214

  • Download
    0

Embed Size (px)

Citation preview

Page 1: gimmenotes.co.za  · Web viewNot necessarily waterfall model. Possibly plan-driven, incremental development. Iteration occurs within activities. Agile Developments. Specification,

Learning Unit 1: Chapter 2 & 3

Objectives:

1. Explain the fundamental concepts of software processes Software is a product designed and built by software engineers. A set of related activities that leads to production of a software product Multiple processes, but four activities that’re fundamental to Software engineering:

i. Specification: Defining what the system should doii. Design and implementation: Defining the organisation of the system and implementing the

system.iii. Validation: Checking the system performs in accordance with customer needsiv. Evolution: Changing the system in response to changing customer needs

Process model: Abstract representations of a process, essentially the activities that are part of these processes. Example:

i. Products: Outcomes of a process activityii. Roles: Responsibilities of people involved in the process

iii. Pre- and post-conditions: Statements that are true before and after a process activity has been enacted.

2. Describe the three generic software processes Not definitive descriptions of software processes, they are abstractions of the process used to explain

different approaches to software development. The waterfall model:

i. Plan-driven model: Separate and distinct phases of specification and development Incremental development:

i. Specification, development, and validation are interleaved – may be plan-driven or agile. Reuse-oriented software engineering:

i. System assembled from existing components, may be plan-driven or agile. Most large systems use elements from all these models when in development.

Page 2: gimmenotes.co.za  · Web viewNot necessarily waterfall model. Possibly plan-driven, incremental development. Iteration occurs within activities. Agile Developments. Specification,

3. Outline the process activities of software requirement engineering, software development, testing and evolution

Software specification: Process of establishing what services are required and constraints on the system’s operation and development.

i. Feasibility Study: Is it technically and financially feasible to build the system?ii. Requirements elicitation and analysis: What do the system stakeholders require or expect of

the system?iii. Requirements specification: Defining detailed requirementsiv. Requirements validation: Checking validity of requirements

Software design and implementation: Process of converting the system specification into an executable system

i. Software design: Design software structure realising the specificationii. Implementation: Translate structures into an executable program.

Page 3: gimmenotes.co.za  · Web viewNot necessarily waterfall model. Possibly plan-driven, incremental development. Iteration occurs within activities. Agile Developments. Specification,

Software validation: Verification and validation is intended to show a system confirms to its specification and meets the customer requirements.

i. Involves checking and reviewing processes and system testingii. System testing involves executing the system with test cases that are derived from the

specification of real data to be processed.iii. Stages:

Component testing: the components making up the system are tested by the people developing the system.

System testing: System components are integrated to create a complete system. Customer testing: This is the final stage in the testing process before the system is

accepted for operational use. The system is tested by the system customer (or potential customer) rather than with simulated test data.

Software Evolution: Inherently flexible and can change. As requirements change through changing business circumstances, the business support software must also evolve and change. Fewer and fewer systems are completely new.

4. Why should processes be organised to cope with changes in the software requirements and design? Change is inevitable in all large software projects

i. Business changes lead to new and changed system requirementsii. New technologies open up new possibilities for improving implementations

iii. Changing platforms require application changes

Reducing costs of rework:i. Change anticipation: Where the software process includes activities that can anticipate

possible changes before significant work is required.ii. Change Tolerance: Where the process is designed so changes can be accommodated at

relatively low costs – Normally involves some form of incremental development.

Page 4: gimmenotes.co.za  · Web viewNot necessarily waterfall model. Possibly plan-driven, incremental development. Iteration occurs within activities. Agile Developments. Specification,

Software prototyping: Initial version of a system used to demonstrate concepts and try out design options.

i. The requirements engineering process to help with requirements elicitation and validationii. Design processes to explore options and develop a UI design

iii. Benefits:1. improved system usability2. a closer match to users’ real needs3. improved design quality4. improved maintainability5. reduced development effort

Incremental Delivery:i. Where some developed increments are delivered to the customer and deployed for use in

their working environmentii. Advantages:

1. Customers can use the early increments as prototypes and gain experience that informs their requirements for later system increments.

2. Customers do not have to wait until the entire system is delivered before they can gain value from it due to satisfying most critical requirements in early increments

3. The process maintains the benefits of incremental development in that it should be relatively easy to incorporate changes into the system.

4. As the highest priority services are delivered first and later increments then integrated, the most important system services receive the most testing.

iii. Disadvantages:1. Iterative delivery is problematic when the new system is intended to replace an

existing system. Users need all of the functionality of the old system and are usually unwilling to experiment with an incomplete new system

2. Most systems require a set of basic facilities that are used by different parts of the system.

3. The essence of iterative processes is that the specification is developed in conjunction with the software.

Process improvement: a way of enhancing the quality of their software, reducing costs, or accelerating their development processes.

i. Two different approaches to improvement and change:1. The process maturity approach, which has focused on improving process and project

management and introducing good software engineering practice into an organization.

a. Process measurement: You measure one or more attributes of the software process or product. These measurements form a baseline

b. Process analysis: The current process is assessed, and process weaknesses and bottlenecks are identified.

c. Process change: proposed to address some of the identified process weaknesses.

Page 5: gimmenotes.co.za  · Web viewNot necessarily waterfall model. Possibly plan-driven, incremental development. Iteration occurs within activities. Agile Developments. Specification,

2. The agile approach, which has focused on iterative development and the reduction of overheads in the software process. The primary characteristics of agile methods are rapid delivery of functionality and responsiveness to changing customer requirements.

5. Explain the rationale for agile software development methods, agile manifesto and the differences between agile and plan-driven development

Methods: The aim of agile methods is to reduce overheads in the software processi. focus on the code rather than the design

ii. are based on an iterative approach to software developmentiii. are intended to deliver working software quickly and evolve this quickly to meet changing

requirements Principles of agile methods:

i. Customer involvement.ii. Embrace change

iii. Incremental deliveryiv. People not processv. Maintain simplicity

Agile Manifesto:i. Individuals and interactions over processes and tools

ii. Working software over comprehensive documentationiii. Customer collaboration over contract negotiationiv. Responding to change over following a plan.

Agile methods have been particularly successful for two kinds of system development.i. Product development where a software company is developing a small or medium-sized

product for sale. Virtually all software products and apps are now developed using an agile approach.

ii. Custom system development within an organization, where there is a clear commitment from the customer to become involved in the development process and where there are few external stakeholders and regulations that affect the software.

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

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

2. Not necessarily waterfall model. Possibly plan-driven, incremental development.3. Iteration occurs within activities

ii. Agile Developments1. 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.

Page 6: gimmenotes.co.za  · Web viewNot necessarily waterfall model. Possibly plan-driven, incremental development. Iteration occurs within activities. Agile Developments. Specification,

6. Discuss the issues and problems of scaling agile development methods to the development of a large software system

Agile methods were developed and refined in projects to develop small to medium-sized business systems and software products, where the software developer controls the specification of the system.

Practical Problems: i. The informality of agile development is incompatible with the legal approach to contract

definition that is commonly used in large companies.ii. Agile methods are most appropriate for new software development rather than for software

maintenance. Yet majority of software costs in large companies come from maintaining their existing software systems.

iii. Agile methods are designed for small co-located teams, yet much software development now involves worldwide distributed teams.

“Pure” agile approach key Issues:i. How large is the system that is being developed? Agile methods are most effective when the

system can be developed with a relatively small co-located team who can communicate informally. This may not be possible for large systems that require larger development teams, so a plan-driven approach may have to be used.

ii. What type of system is being developed? Systems that require a lot of analysis before implementation (e.g., real-time system with complex timing requirements) usually need a detailed design to carry out this analysis. A plan-driven approach may be best in those circumstances.

iii. What is the expected system lifetime? Long-lifetime systems may require more design documentation to communicate the original intentions of the system developers to the support team.

iv. Is the system subject to external regulation? If a system has to be approved by an external regulator (e.g., the Federal Aviation Administration approves software that is critical to the operation of an aircraft), then you will probably be required to produce detailed documentation as part of the system safety case.

Agile methods for large systems:i. Six principal factors contribute to this complexity:

1. Large systems are usually systems of systems—collections of separate, communicating systems, where separate teams develop each system. Frequently, these teams are working in different places, sometimes in different time zones.

2. Large systems are brownfield systems that is, they include and interact with a number of existing systems. Many of the system requirements are concerned with this interaction and so don’t really lend themselves to flexibility and incremental development.

Page 7: gimmenotes.co.za  · Web viewNot necessarily waterfall model. Possibly plan-driven, incremental development. Iteration occurs within activities. Agile Developments. Specification,

3. Where several systems are integrated to create a system, a significant fraction of the development is concerned with system configuration rather than original code development.

4. Large systems and their development processes are often constrained by external rules and regulations limiting the way that they can be developed

5. Large systems have a long procurement and development time. It is difficult to maintain coherent teams who know about the system over that period as, inevitably, people move on to other jobs and projects.

6. Large systems usually have a diverse set of stakeholders with different perspectives and objectives.

ii. Approaches to scaling agile methods have a couple things in common:1. A completely incremental approach to requirements engineering is impossible. Some

early work on initial software requirements is essential.2. Multiple people involved for different parts of the systems with constant

communications and negotiations throughout the development process.3. Not Possible to focus only on the system code. More upfront design and system

documentation is required. Architecture must be designed and there must be documentation for critical system, aspects. Eg Database schemas.

4. Cross-team communication mechanisms have to be designed and used, involving regular calls between team members and frequent electronic meetings with progress updates.

5. Continuous integration, where the whole system is built every time any developer checks in a change, is practically impossible where separate programs have to be integrated to create the system.

iii. Scrum has been adapted for large scale development:1. Role replication: Teams have a product owner for work components and

ScrumMaster.2. Product architects: Collaborate to design and evolve overall system architecture.3. Release alignment: Dates of product releases from each team are aligned so a

demonstrable and complete system is produced.4. Scrum of scrums: Daily scrum of scrums where representative meet to discuss

progress, identify problems, and plan work to done that day.

Page 8: gimmenotes.co.za  · Web viewNot necessarily waterfall model. Possibly plan-driven, incremental development. Iteration occurs within activities. Agile Developments. Specification,

Learning Unit 2: Chapter 4 & 51. Explain the fundamental concepts of user and system requirements and why should these requirements

be written in different wayso User Requirements: What the user wants the system to do

Statements in natural language plus diagrams of the services provided by the system, and the operational constraints

Written for customers, as this is easier for the average person to understand.o System Requirements: What the system needs to do in order to fulfil user requirements

Structured document setting out detailed descriptions of the system’s functions, services, and operational constraints.

Defines what should be implemented, therefore may be part of a contract between clients and contractors.

Page 9: gimmenotes.co.za  · Web viewNot necessarily waterfall model. Possibly plan-driven, incremental development. Iteration occurs within activities. Agile Developments. Specification,

2. Differentiate between functional and non-functional software requirementso Functional:

Statements of services the system should provide How the system should react to different inputs How the system should behave in different situations. Can also state what the system should not do.

o Non-Functional: Constraints on the services or functions offered by the system

Can include:o Timing constraints o Constraints on development processo Constraints imposed by standards

Often applies to a whole system rather than individual system features or services

Page 10: gimmenotes.co.za  · Web viewNot necessarily waterfall model. Possibly plan-driven, incremental development. Iteration occurs within activities. Agile Developments. Specification,
Page 11: gimmenotes.co.za  · Web viewNot necessarily waterfall model. Possibly plan-driven, incremental development. Iteration occurs within activities. Agile Developments. Specification,

3. Explain the principles of requirements engineering activities, elicitation, validation, and the relationships between them

o Elicitation: Understand the work stakeholders do and how they mist use a new system, to assist in

supporting work. Software engineers work with stakeholders to find out about the application domain,

work activities, the services and system features wanted, and the required performance and hardware constraints of the system

Difficulty comes when: Stakeholder soften don’t know what they want from a Computer system except

in general terms. Stakeholders naturally express requirements in their own terms with implicit

knowledge of their own work. Requirements engineers may not understand these.

Different stakeholders, with different requirements may express requirements in difference ways.

Political factors may influence the requirements of a system. Ie manages may demand system requirements increasing their influence in the organisation.

Economic and business environment in this analysis takes place is dynamic. Importance of particular requirements may change.

Process activities: Requirements delivery and understanding:

o Interacting with stakeholders of the system discovering requirements. Requirements classification and organisation:

o Takes unstructured collection of requirements and groups the related requirements and organises them into a coherent structure.

Requirements prioritisation and negotiation: o When multiple stakeholders are involved, requirements will conflict. This

is concerned with prioritising requirements and finding and resolving requirement conflicts through negotiation.

Requirements documentation:o Requirements are documented and input into the next round of the

spiral.

Techniques: Interviewing

o Closed and open interviews Ethnography

o Requirements derived from the way people actually worko Requirements derived from cooperation and awareness of other people’s

activities.

Page 12: gimmenotes.co.za  · Web viewNot necessarily waterfall model. Possibly plan-driven, incremental development. Iteration occurs within activities. Agile Developments. Specification,

o Validation: Validity: Does the system provide functions which best support the customer needs? Consistency: Are there any requirement conflicts? Completeness: are all functions required by the customer included Realism: can the requirements be implemented given available budget and technology? Verifiability: Can the requirements be checked?

o Management: Process of managing changing requirements during the requirements engineering process

and system development. New requirements emerge as a system is being developed and after it has gone into use. Need to keep track of individual requirements and maintain links between dependent

requirements so an assessment of requirement change impacts.

4. Apply graphical models to represent software systems in operationo UML diagram types

Activity diagrams – show the activities involved in a process or in data processing.

Use case diagrams – show the interactions between a system and its environment.

Page 13: gimmenotes.co.za  · Web viewNot necessarily waterfall model. Possibly plan-driven, incremental development. Iteration occurs within activities. Agile Developments. Specification,

Sequence diagrams – show interactions between actors and the system and between system components.

Class diagrams – show the object classes in the system and the associations between these classes.

State diagrams – show how the system reacts to internal and external events.

o Context Diagrams:

Page 14: gimmenotes.co.za  · Web viewNot necessarily waterfall model. Possibly plan-driven, incremental development. Iteration occurs within activities. Agile Developments. Specification,

o Process model:

5. Evaluate the usage of model-driven architecture in system developmento Model Driven engineering:

is an approach to software development where models rather than programs are the principal outputs of the development process

Programs that execute on a hardware/software platform are generated automatically from the models

Supporters of MDE argue it raises the level of abstraction in software engineering so engineers no longer have to be concerned with programming language details or specifics of execution platforms.

o Usage: Still at an early stage of development and unclear whether or not it will have a significant

effect on software engineering practice. Pros:

Allows systems to be considered at higher levels of abstraction Generating code automatically means it is cheaper to adapt systems to new

platforms Cons:

Models for abstraction are not necessarily right for implementation Savings from code generation may be outweighed by costs of translator

developments for new platforms.o Model driven architecture:

Precursor of more general model-driven engineering MDA is the model-focused approach to software design and implementation that uses a

subset of ML models to describe a system. Models are created at different levels of abstraction. From a high level platform

independent model, it is possible to generate a working program without manual intervention.

o recommends that three types of abstract system model should be produced: A computation independent model – Models the important domain abstractions used in a

system. Sometimes called domain models. A platform independent model – models the operation of the system without reference

to its implementation. Usually described using UML models that show static system structure and how it responds to external and internal events.

Page 15: gimmenotes.co.za  · Web viewNot necessarily waterfall model. Possibly plan-driven, incremental development. Iteration occurs within activities. Agile Developments. Specification,

Platform specific models: Transformations of the platform independent model with a separate PSM for

each application platform. In principle, there may be layers of PSM, with each layer adding some platform-specific detail.

o Agile methods and MDA: MDA developers claim it is intended to support an iterative approach to development and

so can be used within agile methods. The notion of extensive up-front modelling contradicts the fundamental ideas in the agile

manifesto and I suspect few agile developers feel comfortable with model-driven engineering.

If transformations can be completely automated, and a complete program generated from a PIM, then, in principle, MDA could be used in an agile development process as no separate coding would be required,

Page 16: gimmenotes.co.za  · Web viewNot necessarily waterfall model. Possibly plan-driven, incremental development. Iteration occurs within activities. Agile Developments. Specification,

Learning Unit 3: Chapter 6 & 71. Explain architectural design in software development

Architectural design is concerned with understanding how a system should be organised and designing the overall structure of that system.

Used in a number of ways:i. As a starting point for the architectural design process

ii. As a design checklistiii. As a way of organising the work of the development teamiv. As a means of assessing components for reusev. As a vocabulary for talking about applications.

First stage in the software design process. Critical link between design and requirements engineering, as it identifies the main structural

components in a system and the relationships between them. Importance:

i. Design process for identifying subsystems making up a system and the framework for subsystem control and communication.

ii. Outputs of the design process are a description of software architecture.1. Stakeholder communication: architecture may be used as a focus of discussion by

stakeholders2. System analysis: means that analysis of whether the can meet its non-functional

requirements is possible.3. Large scale reuse: Architecture muse be reusable across a range of systems and

product-line architectures may be developed.

2. Describe the decisions that must be made about the system architecture during the architectural design process

A Creative process so the process differs depending on the type of system being developed. A number of common decisions span all design processes and those decisions affect the non-

functional characteristics of the systemi. Is there a generic application architecture that can be used?

ii. How will the system be distributed?iii. What architectural styles are appropriate?iv. What approach will be used to structure the system?v. How will the system be decomposed into modules?

vi. What control strategy should be used?vii. How will the architectural design be evaluated?

viii. How should the architecture be documented? Because of close relationships between non-functional requirements and software architecture,

the architectural style and structure chosen for a system should depend on the non-functional system requirements

i. Performance: Critical operations and minimise communications. Use large rather than fine-grain components

ii. Security: Use a layered architecture with critical assets in the inner layers.iii. Safety: Localise safety-critical features in a small number of sub-systemsiv. Availability: Include redundant components and mechanisms for fault tolerance.v. Maintainability: Use fine-grain, replaceable components

3. Show by diagram the architectural patterns that are often used in different types of application systems, including transaction processing systems and language processing systems

i. Patterns are a means of representing, sharing and reusing knowledge.ii. An architectural pattern is a stylised description of good design practice which has been

tried and tested in different environments.

Page 17: gimmenotes.co.za  · Web viewNot necessarily waterfall model. Possibly plan-driven, incremental development. Iteration occurs within activities. Agile Developments. Specification,

iii. Patterns should include info about when they are and are not useful iv. May be represented using tabular and graphical descriptions.

Layered Architecture:i. used to model interfacing of subsystems.

ii. Organises system into a set of layers where each provides a set of servicesiii. Supports incremental development of sub-systems in different layers. When a layer

interface changes, only the adjacent layer is affected.iv. It is often artificial to structure systems in this way

Transaction processing systems: Data-centred applications that process user requests and update information in a system database.

Page 18: gimmenotes.co.za  · Web viewNot necessarily waterfall model. Possibly plan-driven, incremental development. Iteration occurs within activities. Agile Developments. Specification,

Language Processing system: Applications where the users’ intentions are specified in a formal language that is processed and interpreted by the system.

Data processing applications – Data-driven applications process data in batches without explicit user intervention during processing.

Event Processing Systems: - Applications where system actions depend on interpreting events from the system’s environment.

4. Describe the activities in a general, object- oriented design process Software design is a creative activity identifying software components and their relations based

on a customer’s requirements Implementation is the process of realising the design as a program. Wide range of domains, now possible to buy off the shelf systems that are adaptable and tailored

to user requirements. Design process:

i. Structured object-oriented design processes involve developing a number of different system models.

ii. Require a lot of effort for development and maintenance of these models, making it not cost effective for small systems.

iii. Large systems that are developed by many groups, design models are an important communication mechanism

iv. Many different Object-oriented design processes depending on the organisation using the process.

v. Common activities include:1. Defining context and modes of use for the system2. Designing system architecture3. Identifying principal system objects4. Developing design models5. Specify object interfaces.

vi. Examples of design models used: Used to show objects and object classes and relationships between these entities. Static Models describe static structures of the system in terms of object classes and relationships. Dynamic models describe dynamic interactions between objects.

1. Subsystem models: Show logical groupings of objects into coherent subsystems.2. Sequence models: Show sequence of object interactions3. State machines: Show how individual objects change their state in response to

events4. Other models include use-case, aggregations, generalisation models, and so forth

Page 19: gimmenotes.co.za  · Web viewNot necessarily waterfall model. Possibly plan-driven, incremental development. Iteration occurs within activities. Agile Developments. Specification,

5. Explain the issues that must be considered when implementing software, including software reuse and open-source development

i. Reuse: Most modern software is constructed by reusing existing components or systems.ii. Configuration management: During development process, you must keep track of many

different versions of each software components in a configuration management system.iii. Host-target development: Production software does not usually execute on the same

computer as the software development environment. Rather developing it on one computer and executing on another.

Reuse:i. Levels:

1. Abstraction level:a. At this level, software isn’t reused directly, but use knowledge of

successful abstractions in the design of your software.2. Object level:

a. At this level, you directly reuse objects from a library rather than writing the code yourself.

3. The component level:a. Components are collections of objects and object classes that are reused

in application systems.4. The system level:

a. The entire application system is reused Configuration management:

i. Activities may include:1. Version management:

a. Support is provided to keep track of the different versions of software components.

2. System integration:a. Where support is provided to help developers define what versions of

components are used to create each version of a systemb. Then used to build a system automatically by compiling and linking

required components3. Problem tracking:

a. Where support is provided to allow users to report bugs and other problems and to allow all developers to see who is working on these problems and when they are fixed.

Host-Target development:i. Most software is developed on one computer and run on a separate computer.

ii. A platform is more than just hardware, it includes the installed OS plus other supporting software.

iii. Development platforms usually have different installed software than execution platforms, which may have different architectures.

iv. Development platform tools:1. An integrated compiler and syntax directed editing system that allows you to

create and edit code2. A language debugging system3. Graphical editing tools4. Testing tools5. Project support tools

Page 20: gimmenotes.co.za  · Web viewNot necessarily waterfall model. Possibly plan-driven, incremental development. Iteration occurs within activities. Agile Developments. Specification,

Open-source development:i. Approach to software development in which source code of a software system is

published and volunteers are invited to participate in the development process.ii. Open source software extended this idea by using the internet to recruit a much larger

population of development volunteers.

In summary of the study unit

Software architecture is a description of how a software system is organised. Architectural design decisions include decisions on the type of application, the distribution of the system,

and the architectural styles to be used. Architectures may be documented from different perspectives or views such as a conceptual view, a

logical view, a process view and a development view. Architectural patterns are a means of reusing knowledge about generic system architectures. They

describe the architecture; explain when it may be used; and describe its advantages and disadvantages. When developing software, you should always consider the possibility of reusing existing software either

as components, services or complete systems. Configuration management is the process of managing changes to an evolving software system; it is

essential when a team of people are cooperating to develop software. Most software development is host-target development. You use an IDE on a host machine to develop

the software which is transferred to a target machine for execution. Open source development involves making the source code of a system publicly available. This means

that many people can propose changes and improvements to the software.

Page 21: gimmenotes.co.za  · Web viewNot necessarily waterfall model. Possibly plan-driven, incremental development. Iteration occurs within activities. Agile Developments. Specification,

Learning Unit 4: Chapter 8 & 91. Outline the differences between the stages of testing during software development

Testing is the process of executing data using artificial data Intended to show a program can fulfil the intended purpose. Checking results of test runs for errors, anomalies or info about the program’s non-functional

attributes Only reveals presence of errors, not absence. More general verification and validation process also including static validation techniques. Program Testing goals:

i. Validation testing1. Check the software performs correctly given test cases that should show the

expected outcomeii. Defect testing:

1. Test cases are designed to expose defects

2. Differentiate between component, system, release testing and user testing processes Development testing:

i. Unit Testing:1. Where individual program units or object classes are tested in isolation.2. Focused on testing the functionality of objects or methods3. Is a defect testing process.4. Inheritance can make this difficult.

ii. Component Testing:1. Where several individual units are integrated to composite components.

Component testing should focus on testing component interfaces2. Access functionality of these objects through the defined component interface3. Objectives are to defect faults due to interface errors or invalid assumptions

about interfaces4. Interface errors that can occur:

a. Parameter interfaces: In which data or sometimes function references are passed from one component to another. Methods in an object have a parameter interface.

b. Shared memory interfaces: In Which a block of memory is shared between components. Data is placed in the memory by one subsystem and retrieved from there by other subsystems.

c. Procedural interfaces: In which one component encapsulates a set of procedures that can be called by other components. Objects and reusable components have this form of interface.

Page 22: gimmenotes.co.za  · Web viewNot necessarily waterfall model. Possibly plan-driven, incremental development. Iteration occurs within activities. Agile Developments. Specification,

d. Message passing interfaces: In which one component requests a service from another component by passing a message to it. A return message includes the results of executing the service. Some object-oriented systems have this form of interface.

iii. System Testing:1. Where some or all the components in a system are integrated and the system is

tested as a whole. Should focus on testing component interactions.2. Checks that components are compatible, interact correctly, and transfer correct

data at the right time across their interfaces.3. Differences from component testing:

a. Reusable components that have been separately developed and off-the-shelf systems may be integrated with newly developed components. Complete system is then tested.

b. Components developed by different team members or subteams may be integrated at this stage. System testing is a collecting rather than an individual process.

Use case testing:i. Developed to identify system interactions can be used as a basis for system testing

ii. Each use case usually involves several system components so testing the use case forces these interactions to occur.

iii. Sequence diagrams associated with the use case documents the components and interactions that are being tested.

Testing policies:i. Exhaustive system testing is impossible. Therefore testing policies which define required

system test coverage may be developed. Test-driven development:

i. Steps:1. Start by identifying increment of functionality that is required. Normally small and

implementable in a few lines of code.2. Write a test for this functionality and implement as an automated test3. Run test along with all other tests that have been implemented.4. Implement missing functionality and re-run the test.

ii. Benefits:1. Code coverage:

a. Every code segment you write has at least one associated test so all code written has at least one test

2. Regression testing:a. Regression test suite is developed incrementally as a program is

developed.3. Simplified debugging:

a. When tests fail, obvious location of problem. Newly written codes needs to be checked and modified.

4. System documentationa. Tests are a form of documentation that describe what the code should be

doing. Release testing:

i. Process of testing a particular release of a system that is intended for use outside of the development team.

ii. Primary goal is to convince the system supplier that it is good enough for use.iii. Usually a black box testing process where tests are only derived from the system

specification.iv. Release testing is a form of system testing.

Page 23: gimmenotes.co.za  · Web viewNot necessarily waterfall model. Possibly plan-driven, incremental development. Iteration occurs within activities. Agile Developments. Specification,

Performance Testing:i. Part of release testing may involve testing the emergent properties of a system. Such as

performance and reliability.ii. Tests should reflect the profile of use of the system.

User testing:i. User or customer testing is a stage in the testing process during which users or customers

provide input and advice on system testing.ii. Types:

1. Alpha: Users of the software work with development team to test software at the developer’s site.

2. Beta Testing: A release of the software is made available to users to allow them to experiment and to raise problems they discover with the system developers

3. Acceptance Testing: Customers test a system to decide whether or not it is ready to be accepted and deployed in the customer environment.

3. Explain software development and evolution process Software development doesn’t stop after deployment. It continues throughout the system

lifetime. Business changes and changes to user expectations generate new requirements. Software change is inevitable:

i. New requirements emerge when the software is usedii. Business environment changes

iii. Errors must be repairediv. New computers and equipment are added to the systemv. Performance or reliability of the system may have to be improved.

A key problem for all organisations is implementing and managing change to existing software systems.

4. Evaluate software evolution processes Software evolution processes depend on:

i. Type of software being maintainedii. Development processes used

iii. Skills and experience of the people involved Proposals for change are the driver for system evolution

i. Should be linked with components that are affected by the change, thus allowing cost and impact of change to be estimated.

Change identification and evolution continues throughout the system lifetime.

Page 24: gimmenotes.co.za  · Web viewNot necessarily waterfall model. Possibly plan-driven, incremental development. Iteration occurs within activities. Agile Developments. Specification,

Change implementation:i. Iteration of the development process whereby the revisions to the system are designed,

implemented and tested.ii. Critical different is the first stage of change implementation may involve program

understanding especially if original system developers are not responsible for the change implementation.

iii. During program understanding phase, you must understand how the program is structured, how it delivers functionality, and how the proposed change might affect the program.

Maintenance factors affecting maintenance cost:i. Maintenance to repair software faults

ii. Maintenance to adapt new software to a different operating environmentiii. Maintenance to add to or modify the system’s functionality

Maintenance costs:i. Usually greater than development costs

ii. Affected by both technical and non-technical factorsiii. Increases as software is maintained. Maintenance corrupts the software structure so

makes further maintenance more difficultiv. Aging software can have high support costs – Old languages, compilers, etc.

Maintenance cost factors:i. Team stability: Costs reduced if same staff are involved with them for some time

ii. Contractual responsibility: Developers of the system may have no contractual responsibility for maintenance so there is no incentive to design for future change

iii. Staff skills: Maintenance staff are often inexperienced and have limited domain knowledge.

iv. Program age and structure: as programs age, their structure is degraded, and they become harder to understand and change.

5. Explain how legacy systems should be assessed to decide whether they should be scrapped, maintained, reengineered or replaced

Legacy system management: i. Organisations relaying on legacy systems must choose an evolution strategy:

1. Scrap the system completely and modify business processes so that it’s no longer required

2. Continue maintaining the system3. Transform the system by re-engineering to improve its maintainability4. Replace the system with a new system.

ii. The strategy chosen should depend on system quality and business value of the system. Legacy system categories:

i. Low quality, low business value: Should be scrappedii. Low quality, high business value: Make an important business contribution but are

expensive to maintain. Should be re-engineering or replaced if a suitable system is available.

iii. High quality, low business value: replace with COTS, scrap completely, or maintain.iv. High quality, high business value: Continue in operation using normal system

maintenance

Page 25: gimmenotes.co.za  · Web viewNot necessarily waterfall model. Possibly plan-driven, incremental development. Iteration occurs within activities. Agile Developments. Specification,

In summary of the study unit

Testing can only show the presence of errors in a program. It cannot demonstrate that there are no remaining faults.

Development testing is the responsibility of the software development team. A separate team should be responsible for testing a system before it is released to customers.

Development testing includes unit testing, in which you test individual objects and methods component testing in which you test related groups of objects and system testing, in which you test partial or complete systems.

When testing software, you should try to ‘break’ the software by using experience and guidelines to choose types of test case that have been effective in discovering defects in other systems.

Wherever possible, you should write automated tests. The tests are embedded in a program that can be run every time a change is made to a system.

Test-first development is an approach to development where tests are written before the code to be tested.

Scenario testing involves inventing a typical usage scenario and using this to derive test cases. Acceptance testing is a user testing process where the aim is to decide if the software is good enough to

be deployed and used in its operational environment. There are three types of software maintenance, namely bug fixing, modifying software to work in a new

environment, and implementing new or changed requirements. Software re-engineering is concerned with re-structuring and re-documenting software to make it easier

to understand and change. Refactoring, making program changes that preserve functionality, is a form of preventative maintenance.

Page 26: gimmenotes.co.za  · Web viewNot necessarily waterfall model. Possibly plan-driven, incremental development. Iteration occurs within activities. Agile Developments. Specification,

Learning Unit 5: Chapter 10 & 111. Dependable Systems:

a. Dependability Propertiesi. Five Principal dimensions:

1. Availability – Probability it will be up and running and able to deliver useful services at any time

2. Reliability: Probability over a given period of time, that the system will correctly deliver services as expected.

3. Safety: Safety of a system is a judgment of how likely it is that the system can resist accidental or deliberate intrusions

4. Security: Judgement of how likely it is the system can resist accidental or deliberate intrusions

5. Resilience: judgement of how well the system can maintain the continuity of its critical services in the presence of disruptive events.

ii. Other closely-related system properties:1. Repairability2. Maintainability3. Error Tolerance

iii. To build dependable software, you need to ensure:1. Avoid the introduction of accidental errors during software specification and

development2. Design verification and validation processes that are effective in discovering

residual errors affecting dependability3. Design the system to be fault tolerant4. Design protection mechanisms that guard against external attacks affecting

availability or security of the system5. Configure deployed system and supporting software correctly for its operating

environment6. Including system capabilities to recognise external cyberattacks and to resist

these attacks7. Design systems so recovery is quick from system failures and cyberattacks

without critical data loss

Page 27: gimmenotes.co.za  · Web viewNot necessarily waterfall model. Possibly plan-driven, incremental development. Iteration occurs within activities. Agile Developments. Specification,

b. Sociotechnical systems:i. Layers:

1. Equipment layer is composed of hardware devices, some of which may be computers

2. Operating system layer interacts with the hardware and provides a set of common facilities for higher software layers in the system

3. Communications and data management is the middleware that provides access to remote systems and databases

4. Application systems is the specific functionality to meet some organisation requirements

5. Business processes are a set of processes involving people and computer systems supporting business activities

6. Organisations are the higher level strategic business activities affecting system operation

7. Social layer includes the laws, regulations, and cultures that affect system operation.

ii. Characteristics:1. Emergent properties:

a. Properties of the system as a whole that depend on the system components and their relationships

b. Are a consequence of the relationships between system components.c. Can only be assessed and measured once the components have been

integrated into a system.d. Types:

i. Functional:1. These appear when all parts of a system work together to

achieve some objective.ii. Non-functional properties:

1. Examples are reliability, performance, safety and security. These relate to the system behaviour in it operational environment. Often critical for computer-based systems as failure to achieve some minimal defined level in these properties may make the system unusable.

Page 28: gimmenotes.co.za  · Web viewNot necessarily waterfall model. Possibly plan-driven, incremental development. Iteration occurs within activities. Agile Developments. Specification,

2. Non-deterministic properties:a. Not always producing the same output when presented with the same

input because behaviour of the systems is partially dependent on human operators.

b. Deterministic system is one where a given sequence of inputs will always produce the same sequence of outputs.

c. Software systems are deterministic, systems that include humans are non-deterministic

i. A Socio-technical system will not always produce the same sequence of outputs from the same input sequence.

ii. Human elements – People don’t always behave the same.iii. System changes – System behaviour is unpredictable, because of

frequent changes to hardware, software, and data.3. Complex relationships with organisational objectives4. Extent to which the system organisational objectives does not depend on the

system itself.c. Complex Systems:

i. A system is purposeful collection of inter-related components working together achieving a common objective

ii. A system may include software, mechanical, electrical, and electronic hardware and be operated by people

iii. System components are dependent on other system componentsiv. Properties and behaviour of system components are inextricably inter-mingled which

leads to complexityv. System categories:

1. Technical computer-based systems:a. Systems that include hardware and software, but where operators and

operational processes are not considered to be part of the system.b. System is not self-awarec. Example: A word processor used to write a book,

2. Socio-technical systemsa. Systems that include technical systems, but also operational processes

and people who use and interact with the technical systemb. Governed by organisational policies and rulesc. Example: Publishing system to produce a book,

2. Reliability engineering:a. A Fault-error-failure model is based on the notion that human errors cause faults, faults lead to

errors, and errors lead to system failures. Defined as:i. Human Error or mistake

ii. System faultiii. System Erroriv. System fault

b. System faults don’t always result in system errors, and system errors do not necessarily result in system failures

i. Not All code in a program is executedii. Errors are transient

iii. System may include fault detection and protection mechanisms.iv. Users adapt their behaviour using inputs they know cause program failures

Page 29: gimmenotes.co.za  · Web viewNot necessarily waterfall model. Possibly plan-driven, incremental development. Iteration occurs within activities. Agile Developments. Specification,

c. Distinction between faults, errors, and failures leads to 3 complimentary approaches that are used to improve system reliability: (This is not always cost-effective)

i. Fault avoidanceii. Fault detection and correction

iii. Fault toleranced. Two possible types of failure:

i. Transient software failures: Can be repaired by user actions such as resetting or recalibrating the machine. POFOD should be low, ie 0.002 may be acceptable

ii. Permanent software failures: Require the software to be reinstalled by the manufacturer. Probability of failure should much lower. Ie 0.00002

e. Functional reliability specification:i. Checking requirements: Identify checks on inputs to the system ensuring incorrect or out-

of-range inputs are detected prior to being processedii. Recovery Requirements: Geared to helping the system recover after a failure has

occurrediii. Redundancy requirements: Specify redundant features of the system that ensure a single

component failure doesn’t lead to a complete loss of serviceiv. Process requirements: Fault avoidance requirements

f. Protection systems:

g. Self-monitoring architectures:i. A system architecture where the system is designed to monitor its own operation and to

take action if a problem is detected. An aircraft flight system for example.

Page 30: gimmenotes.co.za  · Web viewNot necessarily waterfall model. Possibly plan-driven, incremental development. Iteration occurs within activities. Agile Developments. Specification,

h. N-Version Programming:

i. Software Diversity:i. All of the above fault-tolerant architectures rely on software diversity to achieve fault

tolerance.ii. A company procuring a system may include explicit diversity policies that are intended to

maximise differences between the system versions, examples:1. Including requirements that different design methods should be used.2. By Stipulating programs should be implemented using different programming

languages.3. By Requiring the use of different tools and development environments for the

system4. By requiring different algorithms to be used in some parts of the implementation.

j. Programming for reliability:i. Guideline 1: Control the visibility of information in a program

ii. Guideline 2: Check all inputs for validityiii. Guideline 3: Provide a handler for all exceptionsiv. Guideline 4: Minimize the use of error-prone constructsv. Guideline 5: Provide restart capabilities

vi. Guideline 6: Check array boundsvii. Guideline 7: Include timeouts when calling external components

viii. Guideline 8: Name all constants that represent real-world values

In summary of the study unit

Socio-technical systems include computer hardware, software and people and are designed to meet some business goal.

Human and organisational factors, such as the organisational structure have a significant effect on the operation of socio-technical systems.

Emergent properties are properties that are characteristic of the system as a whole and not of its component parts.

The fundamental stages of systems engineering are procurement, development and operation. System procurement covers all of the activities involved in deciding what system to buy and who should

supply that system. System development includes requirements specification, design, construction, integration and testing. When a system is put into use, the operational processes and the system itself have to change to reflect

changing business requirements.

Page 31: gimmenotes.co.za  · Web viewNot necessarily waterfall model. Possibly plan-driven, incremental development. Iteration occurs within activities. Agile Developments. Specification,

Chapter 12

1. Safety Engineering: A system can be considered safe if it operates without catastrophic failure Software in safety-critical systems have a dual role:

i. System may be software-controlled so decisions made by the software and subsequent actions are safety critical. The software behaviour is directly related to the overall safety of the system.

ii. Software is extensively used for checking and monitoring other safety-critical components in a system.

Software systems that are reliable may not be safe for 4 reasons:i. We can never be 100% certain a software system is fault-free and fault-tolerant.

Undetected faults can be dormant for a long time, and software failures can occur after many years of reliable operation.

ii. The specification may be incomplete in that it does not describe the required behaviour of the system in some critical situations, A high percentage of system malfunctions are the result of specification rather than design errors.

iii. Hardware malfunctions may cause sensors and actuators to behave in an unpredictable way. Components can behave erratically when failing, this could confuse the software.

iv. System operators may generate inputs that are not individually incorrect, in that, in some situations, can lead to a system malfunction.

Safety has to be considered as well as reliability when developing safety-critical systems.

2. Safety-critical systems:i. Primary safety-critical software: Software that is embedded as a controller in a system.

Malfunctioning of such software can cause a hardware malfunction, resulting in human injury or environmental damage. The insulin pump software is an example.

ii. Secondary safety-critical software: Software that can indirectly result in an injury. An example of such software is a computer-aided engineering design system whose malfunctioning might result in a design fault in the object being designed.

Hazard-Driven techniques for fault-avoidance, detection and removal.i. Hazard avoidance: System is designed so hazards are avoided. Such as foot on clutch

before you can start a car.ii. Hazard detection and removal: Designed so hazards are detected and removed before

resulting in an accident. Automatic pressure relief valves for example when pressure gets too high.

iii. Damage limitation: System may include protection features that minimise the damage resulting from an accident. Such as automatic fire extinguishers on an aircraft engine.

Page 32: gimmenotes.co.za  · Web viewNot necessarily waterfall model. Possibly plan-driven, incremental development. Iteration occurs within activities. Agile Developments. Specification,

3. Safety Requirements: Four activities in a hazard-driven safety specifications:

i. Hazard identification: Identifies hazards that may threaten the system. Hazards may be recorded in a hazard register

ii. Hazard assessment: Assessment decides which hazards are the most dangerous and/or the most likely to occur. These should be prioritised.

iii. Hazard analysis: Process of root-cause analysis that identifies events leading to the occurrence of hazards

Page 33: gimmenotes.co.za  · Web viewNot necessarily waterfall model. Possibly plan-driven, incremental development. Iteration occurs within activities. Agile Developments. Specification,

iv. Risk Reduction: Process is based on the outcome of hazard analysis and leads to identification of safety requirements.

4. Safety Engineering process Software processes used to develop safety-critical software are based on the processes used in

software reliability engineering. Some types of safety-critical systems are regulated. National and international regulators require

detailed evidence that the system is safe. Evidence could include:i. Specification of the system that has been developed and records of the checks made on

that specification.ii. Evidence of the verification and validation processes that have been carried out and the

results of the system verification and validation.iii. Evidence the organisations developing the system have defined and dependable software

processes including safety assurance reviews. Safety assurance process:

i. Examples:1. Hazard analysis and monitoring2. Safety reviews3. Safety certification

ii. Individuals having safety responsibilities should be explicitly identified in the hazard register, because:

1. When people are identified, they can be held accountable for their actions. They’re likely to take more care because any problems can be traced back to them

2. In the even of an accident, there may be legal proceedings or an inquiry. It is important to be able to identify those responsible for safety assurance so they can defend their actions as part of the legal process.

Formal verification:1. A formal specification of the system may be developed and mathematically

analysed for inconsistency. This technique is effective in discovering specification errors and omissions.

2. You can formally verify, using mathematical arguments, the code of a software system is consistent with it’s verification.

ii. Formal specification and proof do not guarantee the software will be safe in practical use.1. Specification may not reflect the real requirements of users and other system

stakeholders. 2. Proof may contain errors. Program proofs are large and complex. Just like large

and complex programs, they usually contain errors.3. Proof may make incorrect assumptions about the way the system is used.

Page 34: gimmenotes.co.za  · Web viewNot necessarily waterfall model. Possibly plan-driven, incremental development. Iteration occurs within activities. Agile Developments. Specification,

Model Checking:

1. Involves creating a formal state model of a system and checking the correctness of that model using specialised software tools.

2. Models used by model-checking systems are extended finite-state models of the software.

ii. Static program analysis:1. Software tools that scan the source text of a program and detect possible faults

and anomalies. Parsing the program test and thus recognising the different types of statements in a program.

2. Three levels of checking may be implemented:a. Characteristic error checking: The static analyser knows about common

errors that are made by programmers in languages like Java or Cb. User-defined error checking: The users of the analyser define error

patterns to be detected.c. Assertion checking: Most general and most powerful approach to static

analysis. Developers include formal assertions in their program that state relationships that must hold at that point in a program.

3. Static analysis is effective in finding errors in programs, but commonly generates a large number of false positives.

Page 35: gimmenotes.co.za  · Web viewNot necessarily waterfall model. Possibly plan-driven, incremental development. Iteration occurs within activities. Agile Developments. Specification,

5. Safety Cases:i. Possible contents:

ii. Large and complex documents, therefore expensive to produce and maintain. Structured arguments:

i.

ii.

Page 36: gimmenotes.co.za  · Web viewNot necessarily waterfall model. Possibly plan-driven, incremental development. Iteration occurs within activities. Agile Developments. Specification,

Software safety argument:i. Steps:

1. Start by assuming that an unsafe state, which has been identified by the system hazard analysis, can be reached by executing the program

2. You write a predicate (or logical expression) that defines this unsafe state3. You then systematically analyse a system model or program and show that, for all

program paths leading to that state, the terminating condition of these paths, also defined as a predicate, contradicts the unsafe state predicate.

4. When you have repeated this analysis for all identified hazards, then you have strong evidence the system is safe.

Page 37: gimmenotes.co.za  · Web viewNot necessarily waterfall model. Possibly plan-driven, incremental development. Iteration occurs within activities. Agile Developments. Specification,

Key Points

Safety-critical systems are systems whose failure can lead to human injury or death. A hazard-driven approach may be used to understand the safety requirements for safety-critical systems. You

identify potential hazards and decompose them (using methods such as fault tree analysis) to discover their root causes. You then specify requirements to avoid or recover from these problems.

It is important to have a well-defined, certified process for safety-critical systems development. The process should include the identification and monitoring of potential hazards.

Static analysis is an approach to V & V that examines the source code (or other representation) of a system, looking for errors and anomalies. It allows all parts of a program to be checked, not just those parts that are exercised by system tests.

Model checking is a formal approach to static analysis that exhaustively checks all states in a system for potential errors.

Safety and dependability cases collect all of the evidence that demonstrates a system is safe and dependable. Safety cases are required when an external regulator must certify the system before it is used.

Page 38: gimmenotes.co.za  · Web viewNot necessarily waterfall model. Possibly plan-driven, incremental development. Iteration occurs within activities. Agile Developments. Specification,

Chapter 15:

1. Software re-use:a. Re-use based engineering is a software engineering strategy where development processes are

geared towards reusing existing software.b. Reduces software production maintenance costs, development time, and increased software

quality.c. Examples of reusable software units:

i. System reuse: Complete systems made up of a number of application programs may be reused as part of a system of systems

ii. Application reuse: Can be used without change and incorporated into other systems.iii. Component reuse: Components of an application may be reused. Ranges in size from

subsystems to single objects.iv. Object and function reuse: Software components implements a single function or object

classes may be reused.d. All software systems and components including generic functionality are potentially reusable.

Page 39: gimmenotes.co.za  · Web viewNot necessarily waterfall model. Possibly plan-driven, incremental development. Iteration occurs within activities. Agile Developments. Specification,

2. Software Re-use landscape:a. Key factors to consider:

i. Development schedule for the software: To develop quickly, try reuse complete systems rather than individual components

ii. Expected software lifetime:A long-lifetime system should focus on system maintainability. During the lifetime, system may need adaptations for new requirements.

iii. Background, skills and experience of development teams:Reuse technologies are fairly complex and time consuming to understand and effectively use them.

iv. Criticality of the software and its non-functional requirements:For critical systems requiring external regulator certification, you may need to create a safety or security case for the system. Difficult if you don’t have source code.

v. Application domain:Generic products may be reused by configuring them to a local situation.

vi. Platform for the system:Some component models can be platform specific.

3. Application frameworks:a. Frameworks provide support for generic features that are likely to be used in all applications of a

similar type.b. Frameworks support design reused in that they provide skeleton architectures for the application

as well as reuse of specific classes in systems.c. Implemented as a collection of concrete and abstract object classes in an OOP language.d. Most widely used are WAFs (Web application frameworks) – based on the MVC composite

pattern. MVC consists of the Observer pattern, the strategy pattern, the composite pattern, and more.

e. WAFs provide components and classes supporting:i. Security: User authentication and access control

ii. Dynamic web pages: Classes provided are to help you define web page templates and to populate these dynamically with specific database data.

iii. Database integration: Frameworks don’t usually including a database, but assume separate databases are used.

iv. Session management: Classes to create and manage sessions.v. User interaction

f. Three other classes of framework:i. System infrastructure: Support development of system infrastructures such as

communications, UI, and compilers.ii. Middleware integration frameworks: Consist of a set of standards and associated object

classes supporting component communication and information exchange. .NET and Enterprise Java Beans are examples.

iii. Enterprise application frameworks: Concerned with specific application domains, such as telecommunications or financial systems.

4. Software Product Lines:a. When companies need to support a number of similar but not identical systemsb. Set of applications with common architecture and shared components. Each application is

specialised to reflect specific customer requirements.c. Base application includes:

i. Core components providing infrastructure support. Not usually modified when developing new instances of the product line.

Page 40: gimmenotes.co.za  · Web viewNot necessarily waterfall model. Possibly plan-driven, incremental development. Iteration occurs within activities. Agile Developments. Specification,

ii. Configurable components may be modified and configures to specialise them to a new application.

iii. Specialised, domain-specific components, some or all may be replaced when new instances of product lines are created.

d. Application frameworks and software product lines have much in common. Differences are:i. Application frameworks rely on O-O features such as inheritance and polymorphism to

implement extensions. Software product lines are not necessarily created using an O-O approach.

ii. Most application frameworks provide general support rather than domain-specific support.Software product lines usually embed detailed domain and platform information.

iii. Software product lines are often control applications for equipment.Application frameworks are usually software-oriented, and not usually include hardware interaction components.

iv. Software product lines are made up of a family of related applications, owned by the same organisation.

e. When using an OOP language, an application framework may be used as a system base.f. Components at each level in the product-line system are:

i. Interaction Level:Components provide an operator display interface and an interface with communications systems used.

ii. I/O Management level (level 2):Components handle operator authentication, generate incident reports and vehicle dispatched, support map output and route planning.

iii. Resource Management level (Level 3)Components allow vehicles to be located and dispatched, update vehicle status and equipment, and log incident details.

iv. Database level (Level 4)As well as transaction management support, there are separate database of vehicle, equipment and maps.

Page 41: gimmenotes.co.za  · Web viewNot necessarily waterfall model. Possibly plan-driven, incremental development. Iteration occurs within activities. Agile Developments. Specification,

g. Various software product line specialisations may be developed:i. Platform specialisation:

Versions of the application are developed for different platforms.ii. Environment specialisation:

Versions of the application may be created to handle different operating environments and peripheral devices.

iii. Functional specialisation:Versions of the application may be created for specific customers with different requirements.

iv. Process specialisation:System may be adapted to cope with specific business processes.

h. Process for extending a software product line:i. Elicit Stakeholder requirements

ii. Select the existing system closest fitting the requirementsiii. Renegotiate requirementsiv. Adapt Existing systemv. Deliver new product family member

i. Software product lines are designed to be configurable. Two different stages of changes in development process:

i. Design-time configuration:Organisation that is developing the software modifies a common product-line core by developing, selecting, or adapting components to create a new system for the customer.

ii. Deployment time configuration:A generic system is designed for configuration by a customer or consultants working with the customer. Knowledge of the customer specific requirements and system operating environment is embedded in configuration data used by the generic system.

1. Several levels:a. Component selection:

Where modules in a system providing required functionality are selected.b. Workflow and rule definition:

Workflows are defined and validation rules should apply to information entered by users or generated by the system.

c. Parameter definition:Values of specific system paraments reflecting the instance of the application you’re creating are specified.

2. Can be very complex, and for large systems may take several months to configure and test a system for a customer.

Page 42: gimmenotes.co.za  · Web viewNot necessarily waterfall model. Possibly plan-driven, incremental development. Iteration occurs within activities. Agile Developments. Specification,

5. Application System reuse:a. Application system product is a software system that can be adapted to the needs of different

customers without changing source code of a system.b. Sometimes known as COTS (commercial off the shelf systems) products.c. Benefits over software development:

i. More rapid development of a reliable system may be possible.ii. Possible to see the functionality provided by the applications, so it is easier to judge

whether they are likely to be suitable.iii. Some development risks are avoided by using existing software.iv. Businesses can focus on their core activity without having to devote a lot of system

resources to IT systems development.v. As operating platforms evolve, technology updates may be simplified as these are the

responsibility of the application system vendor rather than the customer.d. Issues:

i. Requirements usually have to be adapted to reflect functionality and mode of operation of the Off the shelf application systems leading to disruptive changes to existing software processes.

ii. Application system may be based on assumptions that are practically impossible to change. Customer must adapt its business to reflect these.

iii. Choosing the correct application system for an enterprise can be a difficult process, especially as many of these systems are not well documented.

iv. May be a lack of local expertise to support systems development.v. System vendor controls system support and evolution. They may go out of business, be

taken over, or make changes causing difficulties for customers.e. Configurable application systems:

i. Generic application systems that may be designed to support a particular business type, activity or sometimes a complete business enterprise. At a larger scale, an ERP (Enterprise Resource Planning) system may support the manufacturing, ordering, and customer relationship management processes in large companies.

ii. Key features of this architecture:1. A number of modules to support different business functions.2. Defined set of business process models, associated with each module, which

relate to activities in that module.3. A common database that maintains information about all related business

functions.4. A set of business rules that apply to all data in the database.

iii. Configuration of these systems may involve:1. Selecting required functionaility from the system2. Establishing a data model deinfing how the organisation’s data will be structured

in the DB.3. Defining business rules applying to data4. Defining expected interactions with external systems.5. Designing input forms and output reports generated.6. Designing new business processes conforming to the underlying process model

supported by the system

Page 43: gimmenotes.co.za  · Web viewNot necessarily waterfall model. Possibly plan-driven, incremental development. Iteration occurs within activities. Agile Developments. Specification,

7. Setting parameters that define how the system is deployed on its underlying platform.

iv. Once configuration is completed, the system is ready for testing, but testing is a major problem when systems are configured rather than programmed using a conventional language:

1. Test automation may be difficult or impossible. May be no easy access to an API that can be used by testing frameworks, so the system must be manually tested by inputting data.

2. System errors are often subtle and specific to business processes. The application system or ERP system is a reliable platform so technical system failures are rare. Problems occurring are usually due to misunderstandings between configurers and user stakeholders.

f. Integrated application systems:i. A number of design choices needed:

1. Which individual application systems offer most appropriate functionality?2. How will data be exchanged?3. What features of a product will actually be used?

ii. Four system integration problems:1. Lack of control over functionality and performance2. Problems with system interoperability3. No control over system evolution4. Support from system vendors.

Key Points

There are many different ways to reuse software. These range from the reuse of classes and methods in libraries to the reuse of complete application systems.

The advantages of software reuse are lower costs, faster software development, and lower risks. System dependability is increased. Specialists can be used more effectively by concentrating their expertise on the design of reusable components.

Application frameworks are collections of concrete and abstract objects that are designed for reuse through specialization and the addition of new objects. They usually incorporate good design practice through design patterns.

Software product lines are related applications that are developed from one or more base applications. A generic system is adapted and specialized to meet specific requirements for functionality, target platform, or operational configuration.

Application system reuse is concerned with the reuse of large-scale, off-the-shelf systems. These provide a lot of functionality, and their reuse can radically reduce costs and development time. Systems may be developed by configuring a single, generic application system or by integrating two or more application systems.

Page 44: gimmenotes.co.za  · Web viewNot necessarily waterfall model. Possibly plan-driven, incremental development. Iteration occurs within activities. Agile Developments. Specification,

Potential problems with application system reuse include lack of control over functionality, performance, and system evolution; the need for support from external vendors; and difficulties in ensuring that systems can interoperate.

Page 45: gimmenotes.co.za  · Web viewNot necessarily waterfall model. Possibly plan-driven, incremental development. Iteration occurs within activities. Agile Developments. Specification,

Chapter 18:

1. Service-oriented software engineering:a. Originally, Client computers gain access to information on remote servers outside their own

organisations solely through a web browser and direct access was not practical..b. Later on, Web services were developed allowing programs to access and update resources

available on the web. A web service is defined as an act or performance offered by one party to another. Although the process may be tied to a physical product, the performance is essentially intangible and does not normally result in ownership of any of the factors of production.

c. A critical distinction between a service and a software component as defined in component based software engineering, is that services should be independent and loosely coupled. In other words, they should always operate the same way, regardless of operating environments differences.

d. Adopting a service-oriented approach to software engineering has a number of important benefits:

i. Services can be offered by any service provider inside or outside an organisation. Assuming the services conform to certain standards, applications can be created by integrating services from multiple providers.

ii. The service provider makes information about the service public so any authorised user can use the service.

iii. Applications can delay the binding of services until they are deployed or until execution. Checking a stock price from multiple providers for example.

iv. Opportunistic construction of new services is possible. A service provider may recognise new services that can be created by linking existing services in innovative ways

v. Service users can pay for services according to their use rather than their provision.vi. Applications can be made smaller, which is important for mobile devices with limited

processing and memory capabilities.

Page 46: gimmenotes.co.za  · Web viewNot necessarily waterfall model. Possibly plan-driven, incremental development. Iteration occurs within activities. Agile Developments. Specification,

2. Service-oriented architecture:a. Architectural style based on the idea that executable services can be included in applications.

b. The fundamental standard for service-oriented architecture are: (All based on XML)i. SOAP

Message interchange standard supporting communication between services defining essential and optional components of messages passed between services.

ii. WSDL: Web Service Description LanguageStandard for service interface definition, setting out how the service operations and service bindings should be defined.

iii. WS-BPELStandard for Workflow language that is used to define process programs involving several different services.

c. The UDDI (Universal Description, Discovery, and Integration) discovery standard that defines components of a service specification intended to help potential users discover the existence of a service. Some of these standards include:

i. WS-Reliable MessagingA Standard for message exchange that ensures messages will be delivered once and once only

ii. WS-SecurityStandards supporting web service security, including standards specifying the definition of security policies and standards that cover the use of digital signatures

iii. WS-AddressingDefines how address information should be represented in a SOAP message.

iv. WS-TransactionsDefines how transactions across distributed services should be coordinated.

d. Service components in an SOA:i. Services in an SOA communicate through messages expressed in XLM, and distributed

through standard protocols, such as HTTP and TCP/IPii. The WSDL defines 3 aspects of a Web Service:

1. What: Called an interface, specifies what operations the service supports and defines the format of the messages sent and received by the service.

2. How: Called a binding, maps the abstract interface to a concrete set of protocols. Specifies the technical details of how to communicate with a Web service.

Page 47: gimmenotes.co.za  · Web viewNot necessarily waterfall model. Possibly plan-driven, incremental development. Iteration occurs within activities. Agile Developments. Specification,

3. Where: Describes the location of a specific Web service implementation (The Endpoint)

iii. Each element in the WSDL Descriptive model is expressed in XML, these elements are:1. Introductory part defining the XML namespaces used and that may include a

documentation section providing additional information about the service.2. Optional description of the types used in the messages exchanged by the service.3. Description of the service interface, that is, the operations that the service

provides for other services and users.4. Description of the input and output messages processed by the service.5. Description of the binding used by the service, that is, the messaging protocol

that will be used to send and receive messages. Default is SOAP, but others may be defined.

6. An endpoint specification that is the physical location of the service expressed as a URI.

3. RESTful servicesa. Initial developments of web services and service-oriented software engineering were standards-

based, with XML based messages exchanged between services.b. The REST architecture is a lightweight approach to web service architecture. Standing for

Representational State Transfer. This is based on transferring representations of resources from a server to a client.

c. Style that underlies the web as a whole, and has been used as a much simpler method that SOAP/WSDL for implementing web service interfaces.

d. Resources are a bit objects, with four fundamental polymorphic operations associated:i. Create – bring resources into existence

ii. Read – return a representation of the resourceiii. Update – change the value of the resourceiv. Delete – make the resource inaccessible.

e. The Web is an example of a system that has a restful architecture. Web pages are resources, and the unique identifier of a web page is the URL.

f. Important difference between RESTful services and SOAP-based services is RESTful services are not exclusively XML based.

g. Fundamental design for RESTful services is that they should be stateless, that is in the interaction session, the resource itself should not include an state information.

Page 48: gimmenotes.co.za  · Web viewNot necessarily waterfall model. Possibly plan-driven, incremental development. Iteration occurs within activities. Agile Developments. Specification,

h. Problems with RESTful approach:i. When a service has a complex interface and is not a simple resource, it can be difficult to

design a set of RESTful services to represent this interface.ii. There are no standards for RESTful interface description, so service users must rely on

informal documentation to understand this interface.iii. When you use restful services, you must implement your own infrastructure for

monitoring and managing the quality of service and the service reliability. SOAP have additional infrastructure support standards, such as WS-Reliability and WS-Transactions.

4. Service Engineering:a. Process of developing services for reuse in service-oriented applications.b. Has a lot in common with component engineering.c. Three logical stages in the service engineering process:

i. Service candidate identification:Where possible services that might be implemented and define service requirements are identified.

1. Three fundamental types of service:a. Utility: Implement some general functionality that may be used by

different business processes.b. Business: These services are associated with a specific business function.c. Coordination or process services: Support a more general business

process that usually involves different actors and activities.

2. You have to think of possible candidates and then ask a series of questions about them to see if they are likely to be useful services, Possible questions to identify potentially reusable services:

a. For an entity-oriented service, is the service associated with a single logical resource that is used in different business processes? What operations are normally performed on that entity that must be supported? Do these fit in with the RESTful service operations?

b. For a task-oriented service, is the task one that is carried out by different people in the organisation? Will they be willing to accept the inevitable standardisation that occurs when a single support service is provided? Can this fit into the RESTful model, or should it be redesigned as an entity-oriented service?

c. Is the service independent?d. Does the service have to maintain state? If state information is required,

this must either be maintained in a database or passed as a parameter to the service.

e. Might this service be used by external clients?f. Are different users of the service likely to have non-functional

requirements?3. Answers to these questions help you select and refine abstractions that can be

implemented as services.

Page 49: gimmenotes.co.za  · Web viewNot necessarily waterfall model. Possibly plan-driven, incremental development. Iteration occurs within activities. Agile Developments. Specification,

ii. Service design:where the logical service interface and its implementation interfaces (SOAP or RESTful) are designed.

1. If SOAP-based services are used, you have to design the input and output messages.

2. If RESTful services are used, you have to think about the resources required and how the standard operations should be used to implement the service operations.

3. Starting point for service interface design is abstract interface design.4. Once you have established an informal description of what the service should do,

the next stage is to add more detail of the service inputs and outputs.

iii. Service implementation and deployment:Where you implement and test the service and make it available for use.

1. This implementation may involve programming the service using a language such as Java or C#. Both of these languages include libraries with extensive support for developing SOAP-based and RESTful services.

2. Information that you may include in a service description might be:

Page 50: gimmenotes.co.za  · Web viewNot necessarily waterfall model. Possibly plan-driven, incremental development. Iteration occurs within activities. Agile Developments. Specification,

a. Information about your business, contact details, and so on. Important for trust reasons.

b. An informal description of the functionality provided by the service.c. A description of the functionality provided by the serviced. Subscription information that allows users to register for information

about updates to the service.

5. Service composition:a. The underlying principle of software engineering is that you compose and configure services to

create new, composite services.b. Both RESTful and SOAP based services can be composed to create services with extended

functionality.c. Six key stages of system construction by composition:

i. Formulate outline workflowUse requirements for the composite service as a basis for creating an “ideal” service design.

ii. Discover servicesDuring this stage, you look for existing services to include in the composition.

iii. Select Possible servicesSelect possible services that can implement workflow activities. Your selection criteria will obviously include functionality of the services offered.

iv. Refine WorkflowAdding detail to the abstract description and perhaps adding or removing workflow activities.

v. Create workflow programThe abstract workflow design is transformed to an executable program and the service interface is defined.

vi. Test completed service or application

d. This process assumes existing services are available for composition.e. Testing issues:

i. External services are under the control of the service provider rather than the user of the service. Service provider may withdraw these services at any time or make changes to them, invalidating previous application testing.

ii. If services are dynamically bound, an application may not always use the same service each time that it is executed. Therefore tests may be successful when an application is bound to a particular service, but it cannot be guaranteed that that service will be used during an actual execution of the system.

iii. The non-functional behaviour of a service is not simply dependent on how it is used by the application that is being tested. A service may perform well during testing, because it is not operating under a heavy load.

iv. The payment model for services could make testing very expensive.v. The notion of compensation actions when an exception occurs and previous

commitments that have been made have to be revoked.f. These problems are particularly acute when external services are used.

Page 51: gimmenotes.co.za  · Web viewNot necessarily waterfall model. Possibly plan-driven, incremental development. Iteration occurs within activities. Agile Developments. Specification,

Key Points

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

Services may be implemented within a service-oriented architecture using a set of XML-based web service standards. These include standards for service communication, interface definition, and service enactment in workflows.

Alternatively, a RESTful architecture may be used, which is based on resources and standard operations on these resources. A RESTful approach uses the http and https protocols for service communication and maps operations on the standard http verbs POST, GET, PUT, and DELETE.

Services may be classified as utility services that provide a general-purpose functionality, business services that implement part of a business process, or coordination services that coordinate the execution of other services.

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

The development of software using services is based on the idea that programs are created by composing and configuring services to create new composite services and systems.

Graphical workflow languages, such as BPMN, may be used to describe a business process and the services used in that process. These

Page 52: gimmenotes.co.za  · Web viewNot necessarily waterfall model. Possibly plan-driven, incremental development. Iteration occurs within activities. Agile Developments. Specification,

Chapter 19:

1. Systems engineering:a. Systems including software fall into 2 categories:

i. Technical computer-based systems – Systems that including hardware and software components but not procedures and processes.

ii. Sociotechnical systems – Include one or more technical systems, but crucially also people who understand the purpose of the system within the system itself.

b. Important for software engineering to know about systems engineering for 2 reasons:i. Software is now the dominant element in all enterprise systems, yet many senior decision

makes in organisations have a limited understanding of softwareii. As a software engineer, it helps if you have a broader awareness of how software

interacts with other hardware and software systems, and the human, social, and organisational factors affecting the way in which the software is used.

c. Four overlapping stages in the lifetime of large, complex systems: Decisions made at any one of these stages can have a profound influence on the other stages.

i. Conceptual Design - It sets out, in nontechnical language, the purpose of the system, why it is needed, and the high-level features that users might expect to see in the system.

ii. Procurement or acquisition - conceptual design is further developed so that information is available to make decisions about the contract for the system development.

iii. Development - Development processes include requirements definition, system design, hardware and software engineering, system integration, and testing.

iv. Operation - the system is deployed, users are trained, and the system is brought into use.

d. An important difference between systems and software engineering is the involvement of a range of professionals throughout the lifetime of the system.

e. Different professional disciplines of developers is essential because of varying component types in complex systems. Although differences may occur:

i. Different professional disciplines often use the same words, but these words do not always mean the same thing. Therefore, misunderstanding are common.

ii. Each discipline makes assumptions about what other disciplines can or cannot do. These assumptions are often based on an inadequate understanding of what is possible.

iii. Disciplines try to protect their professional boundaries and may argue for certain design decisions because these decisions will call for their professional expertise.

Page 53: gimmenotes.co.za  · Web viewNot necessarily waterfall model. Possibly plan-driven, incremental development. Iteration occurs within activities. Agile Developments. Specification,

2. Sociotechnical systems:a. They do not just include software and hardware but also people, processes, and organizational

policies. b. Sociotechnical systems are enterprise systems that are intended to help deliver a business

purpose.

c. Key Elements in an organisation that may affect requirements, design, and operation of a sociotechnical system

i. Process changes – A new system may mean people have to change the way they work, meaning training will be required.

ii. Job changes – New systems may deskill users in an environment or cause them to change the way they work or lose their jobs.

iii. Organisational policies – Proposed system may not be completely consistent with policies. Requiring system changes, policy changes, or process changes.

iv. Organisational politics – System may change the political power structure in an organisation.

d. Sociotechnical systems are complex systems, meaning that it is practically impossible to have a complete understanding, in advance, or their behaviour. This can lead to 3 important characteristics:

i. They have emergent properties that are properties of the system as a whole, rather than associated with individual parts of the system. These depend on both system components and the relationships between them.

ii. They are nondeterministic, so when presented with a specific input, they may not always produce the same output. The behaviour depend on the human operators, and people do not always react in the same way.

iii. Systems success criteria are subjective rather than objective.

e. Emergent properties:i. Examples of emergent properties:

Page 54: gimmenotes.co.za  · Web viewNot necessarily waterfall model. Possibly plan-driven, incremental development. Iteration occurs within activities. Agile Developments. Specification,

ii. Two types:1. Functional emergent properties: When the purpose of a system only emerges

after its components are integrated2. Non functional emergent properties: Relate to the behaviour of the system in its

operational environment. Reliability, performance, safety, and security are examples of these properties. They are critical for computer based systems.

iii. Reliability of a sociotechnical system is influenced by 3 things: (Which affect each other in unpredictable ways)

1. Hardware reliability2. Software reliability3. Operator reliability.

f. Non-determinism:i. People are non-deterministic.

ii. Sociotechnical systems are nondeterministic partly because they include people and partly because changes to the hardware, software, and data in these systems are so frequent.

3. Conceptual Design:a. Very first thing that you do in the systems engineering process.b. Take that initial idea, investigate its feasibility, and develop it to create an overall vision of a

system that could be developed.

c. Conceptual design should always be a team process that involves people from different backgrounds.

d. Managers use the system vision document to understand the system; a procurement team uses it to define a tender document; and requirements engineers use it as a basis for refining the system requirements.

e. Because these different people need different levels of detail, I suggest that the document should be structured into two parts:

i. A short summary for senior decision makers presenting key points for the problem and the proposed system. Should be written so readers can immediately see how the system will be used and benefits that it will provide.

Page 55: gimmenotes.co.za  · Web viewNot necessarily waterfall model. Possibly plan-driven, incremental development. Iteration occurs within activities. Agile Developments. Specification,

ii. A number of appendices that develop the ideas in more detail and that can be used in the system procurement and requirements engineering activities.

4. System Procurement:a. Process whose outcome is a decision to buy one or more systems from system suppliers.b. The drivers for these decisions:

i. The replacement of other organisational systems. When there is a mixture of systems that cannot work together or are too expensive to maintain, the procure a replacement system.

ii. The need to comply with external regulationsiii. External competition:

Improve business efficiency or effectiveness when a business needs to compete more effectively or maintain a competitive position.

iv. Business reorganisation:Restructuring with the intention of improving efficiency and or customer service.

v. Available budgetc. Large complex systems are usually engineered using a mixture of off-the-shelf and specially built

components. They are often integrated with existing legacy systems and organizational databases. Three types of systems may need to be procured:

i. Off the shelf applications that may be used without change and minimal configurationii. Configurable application or ERP systems may have to be modified or adapted for use by

modifying code or using inbuilt configuration featuresiii. Custom systems that have to be specially designed and implemented for use.

d. Each of these components leads to a different procurement process.i. Organizations often have an approved and recommended set of application software that

has been checked by the IT departmentii. Off-the-shelf components do not usually match requirements exactly, unless the

requirements have been written with these components in mind.iii. When a system is to be built specially, the specification of requirements is part of the

contract for the system being acquired. It is therefore a legal as well as a technical document.

iv. For public sector systems in particular, there are detailed rules and regulations that affect the procurement of systems

v. For application systems that require change or for custom systems, there is usually a contract negotiation period when the customer and supplier negotiate the terms and conditions for development of the system

Page 56: gimmenotes.co.za  · Web viewNot necessarily waterfall model. Possibly plan-driven, incremental development. Iteration occurs within activities. Agile Developments. Specification,

5. System development:a. Complex process in which elements part of the system are developed or purchased and then

integrated to create a final system.b. System requirements are the bridge between conceptual design and development process.c. 7 Fundamental development activities:

i. Requirements engineeringii. Architectural design

iii. Requirements partitioningiv. Subsystem engineeringv. System integration

vi. System testingvii. System deployment

d. An incremental integration process where subsystems are integrated one at a time is the best approach:

i. Usually impossible to schedule the development of all the subsystems so that they are all finished at the same time.

ii. Incremental integration reduces the cost of error location. If many subsystems are simultaneously integrated, an error that arises during testing may be in any of these subsystems.

6. System operation and evolution:a. Operational processes are the processes that are involved in using the system as intended by its

designers.b. Some people think that system operators are a source of problems in a system and that we

should move toward automated systems where operator involvement is minimized.i. Likely to increase the technical complexity of the system because it has to be designed to

cope with all anticipated failure modes. Increasing costs time required to build the system.

ii. People are adaptable and can cope with problems and unexpected situations.c. System evolution:

i. Large, complex systems usually have a long lifetime.ii. Over their lifetime, large complex systems change and evolve to correct errors in the

original system requirements and to implement new requirements that have emerged.iii. Costly for several reasons:

1. Proposed changes have to be analysed very carefully from a business and a technical perspective

Page 57: gimmenotes.co.za  · Web viewNot necessarily waterfall model. Possibly plan-driven, incremental development. Iteration occurs within activities. Agile Developments. Specification,

2. Because subsystems are never completely independent, changes to one subsystem may have side-effects that adversely affect the performance and behaviour of other subsystems. Consequent changes may therefore be needed.

3. Reasons for original design decisions are often unrecorded. These reasons then have to be worked out.

4. As systems age, their structure becomes corrupted by changes. So costs of making further changes may occur.

Key Points

Systems engineering is concerned with all aspects of specifying, buying, designing, and testing complex sociotechnical systems.

Sociotechnical systems include computer hardware, software, and people, and are situated within an organization. They are designed to support organizational or business goals and objectives.

The emergent properties of a system are characteristics of the system as a whole rather than of its component parts. They include properties such as performance, reliability, usability, safety, and security.

The fundamental systems engineering processes are conceptual systems design, system procurement, system development, and system operation.

Conceptual systems design is a key activity where high-level system requirements and a vision of the operational system is developed.

System procurement covers all of the activities involved in deciding what system to buy and who should supply that system. Different procurement processes are used for off-the-shelf application systems, configurable COTS systems, and custom systems.

System development processes include requirements specification, design, construction, integration, and testing.

When a system is put into use, the operational processes and the system itself inevitably change to reflect changes to the business requirements and the system’s environment.