Review se

Review

12/11/09

Software Engineering ≠ Software Programming

• Software programming– Single developer– Limited Lifespan– Single or few stakeholders

• Architect = Developer = Manager = Tester = Customer = User

– One-of-a-kind systems– Built from scratch– Minimal maintenance

Software Engineering ≠ Software Programming

• Software engineering– Teams of developers with multiple roles– Complex systems– Indefinite lifespan– Numerous stakeholders

• Architect ≠ Developer ≠ Manager ≠ Tester ≠ Customer ≠ User

– System families– Reuse to amortize costs– Maintenance accounts for over 60% of overall

development costs

Economic and Management Aspects of SE

• Software production =development + maintenance (evolution)

• Maintenance costs > 60% of all development costs– 20% corrective– 30% adaptive– 50% perfective

• Quicker development is not always preferable– higher up-front costs may defray downstream costs– poorly designed/implemented software is a critical

cost factor

What is software engineering?

• Software engineering is an engineering discipline which is concerned with all aspects of software production

• Software engineers should adopt a systematic and organised approach to their work and use appropriate tools and techniques depending on – the problem to be solved,– the development constraints, and– the resources available

• A key software engineering “axiom”– Better– Cheaper pick any two– Faster

What is the difference between software engineering and computer science?

• Computer science is concerned with theory and fundamentals

• Software engineering is concerned with the practicalities of developing and delivering useful software

• Computer science theories are currently insufficient to act as a complete underpinning for software engineering

What is a software process?

• A set of activities and results that produce a software product

• Generic activities in all software processes are:– Specification - what the system should do and its

development constraints– Development - production of the software system– Validation - checking that the software is what the

customer wants– Evolution - changing the software in response to

changing demands

What are the attributes of good software?

• Software should deliver the required functionality and performance, and should be maintainable, dependable and usable

• Maintainability– Software must evolve to meet changing needs

• Dependability– Software must be trustworthy

• Efficiency– Software should not waste system resources

• Usability– Software must be usable by the users for which it was designed

• There are many others!

Software Systems

Systems that include software fall into groups:• Technical Computer-based systems: Include

software and hardware system but not processes and procedures. (e.g., tv, phone)

• Socio-technical systems: Include one or more technical systems but also some broader knowledge to achieve the objectives

Emergent properties

• Properties of the system as a whole rather than properties that can be derived from the properties of components of a system

• Emergent properties are a consequence of the relationships between system components

• They can therefore only be assessed and measured once the components have been integrated into a system

Types of emergent property

• Functional properties

– These appear when all the parts of a system work together to achieve some objective.

Example: A bicycle has the functional property of being a transportation device once it has been assembled from its components.

• Non-functional emergent properties– Behaviour of a system in operational environment

Examples: reliability, performance, safety, and security.

System Requirements

• What system should do?

– Functional Requirements– System Properties (Non functional emergent

properties)– Characteristics what system shouldn’t do

(limitations of the system)

Example• Functional Requirement: To provide a fire and

intruder alarm system for the building that will provide internal and external warning of fire or unauthorized intrusion.

• System Property: The alarm should set of within 4 seconds

• Characteristics that the system should not exhibit: The alarm shouldn’t run more than 30 minutes

3.2. Dependability

• The dependability of a system equates to its trustworthiness.

• A dependable system is a system that is trusted by its users.

• Principal dimensions of dependability are:– Availability;– Reliability;– Safety;– Security

Dimensions of dependability

Dependability

Availability Reliability Security

The ability of the systemto deliver services when

requested

The ability of the systemto deliver services as

specified

The ability of the systemto operate withoutcatastrophic failure

The ability of the systemto protect itelf against

accidental or deliberateintrusion

Safety

Costs of increasing dependability

Low Medium High Veryhigh

Ultra-high

Dependability

Availability and reliability

• Reliability– The probability of failure-free system

operation over a specified time in a given environment for a given purpose

• Availability– The probability that a system, at a point in

time, will be operational and able to deliver the requested services

• Both of these attributes can be expressed quantitatively

The software process• A structured set of activities required to develop a

software system– Specification– Design– Validation– Evolution

• A software process model is an abstract representation of a process. It presents a description of a process from some particular perspective

Software lifecycle models:Generic software process models

• The waterfall model– Separate and distinct phases of specification

and development• Evolutionary development

– Specification and development are interleaved

• Reuse-based development– The system is assembled from existing

components

Waterfall model problems

• Inflexible partitioning of the project into distinct stages

• The main drawback of the waterfall model is

One phase has to be complete before moving onto the next phase

• This makes it difficult to respond to changing customer requirements

• This model is only appropriate when the requirements are well-understood

Evolutionary developmentMore focused on customer needs

• Exploratory development

– Objective is to work with customers and to evolve a final system from an initial outline specification.

– Start with well-understood requirements and adds on

• Throw-away prototyping

– Objective is to understand the system requirements.

– Experiment poorly understood customer requirements

Evolutionary development• Problems

– Systems are often poorly structured due to lack of proper planning

– Special skills (e.g. in languages for rapid prototyping) may be required

• Applicability– For small or medium-size interactive systems– For parts of large systems (e.g. the user interface)– For short-lifetime systems

Reuse-oriented (Component Based) development

• Based on systematic reuse where systems are integrated from existing components or COTS systems

• Process stages– Component analysis– Requirements modification– System design with reuse– Development and integration

• Becoming important but still limited experience with it

Requirementsspecification

Componentanalysis

Developmentand integration

System designwith reuse

Requirementsmodification

Systemvalidation

Process iteration

• System requirements always evolve in the course of a project

• Two kind of iterative process models

– Incremental development

– Spiral development

Why Incremental development?

• Waterfall:– Changes on requirements require changes in

all phases.

• Evolutionary: requirements and design could be delayed, poorly designed, bad documentation

• Incremental delivery: Combined the advantages of the both models

Incremental development

• Development and delivery is broken down into increments

• Each increment delivers part of the required functionality• Requirements are prioritized and the highest priority

requirements are included in early increments• Once the development of an increment is started, the

requirements are frozen– Requirements for later increments can continue to

evolve

Spiral development

• Process is represented as a spiral rather than as a sequence of activities with backtracking

• Each loop in the spiral represents a phase in the process.

• No fixed phases such as specification or design - loops in the spiral are chosen depending on what is required

• Risks are explicitly assessed and resolved throughout the process

Spiral model of the software process

Riskanalysis

Riskanalysis

Riskanalysis

Riskanalysis Proto-

type 1

Prototype 2Prototype 3

Opera-tionalprotoype

Concept ofOperation

Simulations, models, benchmarks

S/Wrequirements

Requirementvalidation

DesignV&V

Productdesign Detailed

design

CodeUnit test

IntegrationtestAcceptance

testService Develop, verifynext-level product

Evaluate alternativesidentify, resolve risks

Determine objectivesalternatives and

constraints

Plan next phase

Integrationand test plan

Developmentplan

Requirements planLife-cycle plan

REVIEW

• Concerned with activities involved in ensuring that software is delivered– on time– within the budget– in accordance with the requirements

• Project management is needed because software development is always subject to budget and schedule constraints – Set by the development organisation or the customer

Software project management

• The product is intangible (Progress can’t be seen)• The product is uniquely flexible• The product is uniquely complex• The software development process is not

standardised• Many software projects are “one-off” projects (Lesson

learned from previous projects might not be applied)

Software management distinctions

Project plan concerned with development process

• Set project constraint (time, budget …)

• Project organisation (team and roles)

• Risk Analysis

• Hardware/sofrware resource requirements

• Work Breakdown (identify milestones)

• Project schedule (milestones, people…)

• Project monitoring

Bar charts and activity networks• Graphical notations used to illustrate the

project schedule

• Show project breakdown into tasks– Tasks should not be too small– They should take about a week or two

• Activity charts show task dependencies and the the critical path

• Bar charts show schedule against calendar time

Task durations and dependencies

Task Duration (days) DependenciesT1 8T2 15T3 15 T1 (M1)T4 10T5 10 T2, T4 (M2)T6 5 T1, T2 (M3)T7 20 T1 (M1)T8 25 T4 (M5)T9 15 T3, T6 (M4)T10 15 T5, T7 (M7)T11 7 T9 (M6)T12 10 T11 (M8)

Activity network

start

T2

M3T6

Finish

T10

M7T5

T7

M2T4

M5

T8

4/7/99

8 days

14/7/99 15 days

4/8/99

15 days

25/8/99

7 days

5/9/99

10 days

19/9/99

15 days

11/8/99

25 days

10 days

20 days

5 days25/7/99

15 days

25/7/99

18/7/99

10 days

T1

M1 T3T9

M6

T11

M8

T12

M4

Critical Path: The minimum time required to finish the project (i.e the longest path in the activity graph)

Activity timeline – Gantt chart4/7 11/7 18/7 25/7 1/8 8/8 15/8 22/8 29/8 5/9 12/9 19/9

T4

T1T2

M1

T7T3

M5T8

M3

M2T6

T5M4

T9

M7T10

M6

T11M8

T12

Start

Finish

Risk management

• Risk management is concerned with identifying risks and drawing up plans to minimise their effect on a project.

• A risk is a probability that some adverse circumstance will occur. – Project risks affect schedule or resources– Product risks affect the quality or performance of

the software being developed– Business risks affect the organisation developing

or procuring the software

The risk management process

• Risk identification – Identify project, product and business risks• Risk analysis – Assess the likelihood and consequences of risks• Risk planning – Draw up plans to avoid/minimise risk effects• Risk monitoring – Monitor the risks throughout the project and mitigate

risks

Risk avoidanceand contingency

plans

Risk planning

Prioritised risklist

Risk analysis

List of potentialrisks

Riskidentification

Riskassessment

Riskmonitoring

Risk identification

• Technology risks

• People risks

• Organisational risks

• Requirements risks

• Estimation risks

Risk analysis

• Assess probability and seriousness of each risk• Probability may be

– very low– low– moderate– high– very high

• Risk effects might be– catastrophic– serious– tolerable– insignificant

Risk planning

• Consider each risk and develop a strategy to manage that risk

• Avoidance strategies– The probability that the risk will arise is reduced

• Minimisation strategies– The impact of the risk on the project or product will be

reduced• Contingency plans

– If the risk arises, contingency plans are plans to deal with that risk

Requirements engineering• The process of establishing the services that

the customer requires from a system and the constraints under which it operates and is developed

• Requirements specify what the system is supposed to do, but not how the system is to accomplish its task

What is a requirement?

• It may span a wide range of statements– from a high-level abstract statement of a service

or of a system constraint– to a detailed mathematical functional specification

• Types of requirements– User requirements– System requirements

• Software specifications – provide more (design) detail

User requirements

• Should describe functional and non-functional requirements in such a way that they are understandable by system users who don’t have detailed technical knowledge.

• User requirements are defined using natural language, tables and diagrams as these can be understood by all users.

System requirements

• More detailed specifications of user requirements

• Serve as a basis for designing the system

• May be used as part of the system contract

Functional and non-functional requirements

• Functional requirements– Describe functionality or system services.

– Depend on the type of software, expected users and the type of system where the software is used.

– Functional user requirements may be high-level statements of what the system should do but functional system requirements should describe the system services in detail.

– Inputs, outputs and exceptions

• Non-functional requirements– constraints on the services or functions offered by the system such as timing

constraints, constraints on the development process, standards, etc.

– They usually apply to the system as a whole

• Domain requirements– Requirements that come from the application domain of the system and that

reflect characteristics of that domain

Examples of functional requirements

For the library systems the following are functional

requirements

• The user shall be able to search either all of the initial set of databases or select a subset from it.

• The system shall provide appropriate viewers for the user to read documents in the document store.

• Every order shall be allocated a unique identifier (ORDER_ID) which the user shall be able to copy to the account’s permanent storage area.

Requirements precision, completeness, and consistency

• In principle requirements should be precise, complete, and consistent

• Precise– They should state exactly what is desired of the system

• Complete– They should include descriptions of all facilities required

• Consistent– There should be no conflicts or contradictions in the

descriptions of the system facilities• In practice, it is very difficult to produce a complete and

consistent requirements document

Non-functional requirements• These are the requirements that are not directly concerned

with the specific functions delivered by the system and might relate to emergent system properties such as reliability response time…

• They define system properties and constraints e.g. reliability, response time and storage requirements. Constraints are I/O device capability, system representations, etc.

• Process requirements may also be specified mandating a particular CASE system, programming language or development method.

• Non-functional requirements may be more critical than functional requirements. If these are not met, the system is useless.

Non-functional requirement types

Performancerequirements

Spacerequirements

Usabilityrequirements

Efficiencyrequirements

Reliabilityrequirements

Portabilityrequirements

Interoperabilityrequirements

Ethicalrequirements

Legislativerequirements

Implementationrequirements

Standardsrequirements

Deliveryrequirements

Safetyrequirements

Privacyrequirements

Productrequirements

Organizationalrequirements

Externalrequirements

Non-functionalrequirements

Domain requirements

• Derived from the application domain and describe system characteristics and features that reflect the domain.

• Domain requirements be new functional requirements, constraints on existing requirements or define specific computations.

• If domain requirements are not satisfied, the system may be unworkable.

Guidelines for writing requirements

• Invent a standard format and use it for all requirements.

• Use language in a consistent way. Use shall for mandatory requirements, should for desirable requirements.

• Use text highlighting to identify key parts of the requirement.

• Avoid the use of computer jargon.

The requirements document• The requirements document is the official

statement of what is required of the system developers.

• Should include both a definition of user requirements and a specification of the system requirements.

• It is NOT a design document. As far as possible, it should set of WHAT the system should do rather than how it should do it

Requirements Engineering• Feasibility studies

• Requirements elicitation and analysis

• Requirements validation

• Requirements management

Requirements engineering processes

• The processes used for RE vary widely depending on the application domain, the people involved and the organisation developing the requirements.

• However, there are a number of generic activities common to all processes– Requirements elicitation;– Requirements analysis;– Requirements validation;– Requirements management.

Feasibility studies

• A feasibility study decides whether or not the proposed system is worthwhile.

• A short focused study that checks– If the system contributes to organisational

objectives;– If the system can be engineered using current

technology and within budget;– If the system can be integrated with other

systems that are used.

Feasibility study implementation

• Based on information assessment (what is required), information collection and report writing.

• Questions for people in the organisation– What if the system wasn’t implemented?– What are current process problems?– How will the proposed system help?– What will be the integration problems?– Is new technology needed? What skills?– What facilities must be supported by the proposed

system?

Elicitation(reveal) and analysis• Sometimes called requirements elicitation or

requirements discovery.• Involves technical staff working with customers

to find out about the application domain, the services that the system should provide and the system’s operational constraints.

• May involve end-users, managers, engineers involved in maintenance, domain experts, trade unions, etc. These are called stakeholders.

Problems of requirements analysis

• Stakeholders don’t know what they really want.• Stakeholders express requirements in their own

terms.• Different stakeholders may have conflicting

requirements.• Organisational and political factors may

influence the system requirements.• The requirements change during the analysis

process. New stakeholders may emerge and the business environment change.

Scenarios

• Scenarios are real-life examples of how a system can be used.

• They should include– A description of the starting situation;– A description of the normal flow of events;– A description of what can go wrong;– Information about other concurrent activities;– A description of the state when the scenario

finishes.

Use cases

• Use-cases are a scenario based technique in the UML which identify the actors in an interaction and which describe the interaction itself.

• A set of use cases should describe all possible interactions with the system.

• Sequence diagrams may be used to add detail to use-cases by showing the sequence of event processing in the system.

MBASE Guidelines

• Model-based System Architecting and Software Engineering (MBASE) is an approach that integrates the process (PS), product (PD), property (PY) and success (SS) models for developing a software system. It consist of the following documentation pieces

• Operational Concept Description (OCD) • System and Software Requirements Definition (SSRD) • System and Software Architecture Description (SSAD) • Life Cycle Plan (LCP) • Feasibility Rationale Description (FRD)

Operational Concept Description (OCD)

• The Operational Concepts Description (OCD) tells how a proposed new system will operate within its environment. For the operational stakeholders (including users, operators, administrators, maintainers, owners, general public), it enables them to understand and refine the proposed new system

• Organizational Goals• Key Stakeholders• System Boundaries and Environment• Project and Goal and Constraints• System Capabilities

Requirements Definition• Requirements describe all the services provided by the system and

include Level of Service Requirements as needed. Every single detail that designers need to know must appear in the requirements definition. If it's not here then:

• it doesn't get implemented, or • the designers guess at the details

Basic Categorization:

Project RequirementsSystem Requirements

System Models:The Unified Modeling Language

• Devised by the developers of object-oriented analysis and design methods

• Has become an effective standard for software modelling• Has nine different notations

Use CaseDiagrams

Use CaseDiagrams

Use CaseDiagrams

ScenarioDiagrams

ScenarioDiagrams

CollaborationDiagrams

StateDiagrams

StateDiagramsComponentDiagrams

ComponentDiagramsComponent

DiagramsDeploymentDiagrams

StateDiagrams

StateDiagrams

ObjectDiagrams

ScenarioDiagrams

ScenarioDiagramsStatechartDiagrams

Use CaseDiagrams

Use CaseDiagramsSequenceDiagrams

StateDiagrams

StateDiagrams

ClassDiagrams

ActivityDiagrams

Models

Fig. 3-53, UML Notation Guide

Customer

Supervisor

SalespersonPlace

Establishcredit

Check

Telephone Catalog

F ill orde rs

Shipping Clerk

status

order

Use Case Diagram

When to model use cases• Model user requirements with use cases.• Model test scenarios with use cases.• If you are using a use-case driven

method– start with use cases and derive your

structural and behavioral models from it.

• If you are not using a use-case driven method– make sure that your use cases are consistent

with your structural and behavioral models.

The context of an ATM system

Auto-tellersystem

Securitysystem

Maintenancesystem

Accountdatabase

Usagedatabase

Branchaccounting

system

Branchcountersystem

Process models

• Process models show the overall process and the processes that are supported by the system.

• Data flow models may be used to show the processes and the flow of information from one process to another.

• These types of diagram are sometimes known as workflow diagrams.

Equipment procurement process

Get costestimates

Acceptdelivery ofequipment

Checkdelivered

items

Validatespecification

Specifyequipmentrequired

Choosesupplier

Placeequipment

order

Installequipment

Findsuppliers

Supplierdatabase

Acceptdelivered

equipment

Equipmentdatabase

Equipmentspec.

Checkedspec.

Deliverynote

Deliverynote

Ordernotification

Installationinstructions

Installationacceptance

Equipmentdetails

Checked andsigned order form

Orderdetails plusblank order

form

Spec. +supplier +estimate

Supplier listEquipment

spec.

Object models• Object models describe the system in terms of

object classes• An object class is an abstraction over a set of

objects with common attributes and the services (operations) provided by each object

• Various object models may be produced– Inheritance models– Aggregation models– Interaction models

Library class hierarchy

Catalogue numberAcquisition dateCostTypeStatusNumber of copies

Library item

Acquire ()Catalogue ()Dispose ()Issue ()Return ()

AuthorEditionPublication dateISBN

Book

YearIssue

MagazineDirectorDate of releaseDistributor

Film

VersionPlatform

Computerprogram

TitlePublisher

Published item

TitleMedium

Recorded item

Object interaction (Sequence Diagram)

:Library User

Ecat:Catalog

Lookup

Issue

Display

:Library Item Lib1:NetServer

Issue licence

Accept licence

Compress

Deliver

Implement the transformations by using a sequence of filter components, where each filter component receives an input message, applies a simple transformation, and sends the transformed message to the next component

Object Oriented Software Design Characteristics

• Objects are abstractions of real-world or system entities and manage themselves

• Objects are independent and encapsulate state and representation information.

• System functionality is expressed in terms of object services

• Shared data areas are eliminated

– Objects communicate by message passing

• Objects may be distributed

• Objects may execute sequentially or in parallel

77

Client-Server Style

• Components are clients and servers• Servers do not know number or identities of clients• Advantage:

- It is a distributed architecture

- It is easy to add a new server and

integrate it with the rest of the system • Disadvantage:

- Changes to existing clients and servers may be required. No shared data model across servers

Film and picture library

Catalogueserver

Librarycatalogue

Videoserver

Film clipfiles

Pictureserver

Digitisedphotographs

Web server

Film andphoto info.

Client 1 Client 2 Client 3 Client 4

Internet

Layered Architecture Example :Version management system

Configuration management system layer

Database system layer

Operating system layer

Object management system layer