Loading presentation...

Present Remotely

Send the link below via email or IM

Copy

Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in our knowledge base article

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.

DeleteCancel

Make your likes visible on Facebook?

Connect your Facebook account to Prezi and let your likes appear on your timeline.
You can change this under Settings & Account at any time.

No, thanks

SE-best practices

No description
by

Za F

on 16 March 2014

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of SE-best practices

Best Practices
Software Engineering
Introduction to SE
Software Process
Models
Configuration Management
Agile
Dependability
Distributed
Systems

Software Engineering- engineering discipline
that is concerned with all aspects of software production:
-technical process of development;
- project management;
- development of tools, methods, theories to
support professional software production.
1. Individuals and interactions over processes and tools
The ability of the system to protect itself against accidental or deliberate intrusion;
Scalability
Increased throughput by adding new resources
Security
Availability
Availability to deliver service and perform AS EXPECTED
Deliver services WHEN requested
Reliability
Ability to deliver the services AS SPECIFIED
Safety
System does not behave in unsafe way
Trust
It reflects users degree of the trust of the system.
If the customers do not trust the system, they may reject it.
SYSTEM FAILURE- result of system errors
-> affect people = > cost
-> information lost -> recovery cost
FAILURE types
Hardware
- design & maintenance errors;
- components reached the end of their natural life;
Software
- due to errors in specification, design or implementation;
Operational
-human errors (socio-technical)
System properties- the attributes that lead to dependability
Other
SURVIVABILITY
- the extend to which the system can deliver services whilst under attack
-subsumes the notion of resilience, the ability of a system to continue in operation in spite of
component failures
MAINTAINABILITY
(long term perspective)
- the extend to which the system can be adopted to new requirements
-is concerned with the ease of
repairing the system after a failure has been discovered
or changing the system to include new features.
ERROR TOLERANCE
- the extend to which user input
errors can be avoided, detected or tolerated
- User errors should, as far as possible, be detected and
corrected automatically and should not be passed on to
the system and cause failures.
REPAIRABILITY
(short term perspective)
-extend to which
the disruptions
can be minimalised
-requires problem diagnosis,
access to the failed
component(s) and
making changes to fix the problems.
Testing
Introduction
Process of software (B. Boehm):
- VERIFICATION - are we building the PRODUCT RIGHT?
- VALIDATION- are we building the RIGHT PRODUCT?
Is the software fit for purpose?
Does the software being developed meets its specification?
Does it deliver the functionality expected by those whopay for the software?
Software inspections/reviews
Code refactoring
Issues:
- additional errors can
be masked by existing errors;
- Testing only shows the presence
of the errors not their absence;
Component:
- related group of methods,
Unit testing:
- individual methods & objects;
Release testing
process of testing a particular release of a system that is intended for use outside the development team
often BLACK BOX TESTING
- tests derived from the system spec.
- behaviors are determined by studying system inputs/outputs
- functionality testing ( not implementation)
Requirements should be tested
- validation rather than defect testing;
Scenarios testing- few requirements in one scenario
WHITE BOX TESTING
Performance testing
- ensure that system can process its intended load;
- running a series of tests - adding volume (operational file may be developed);
- design the tests around the limits of the system.
Relevant to DISTRIBUTED SYSTEMS based on a network of processors;
- severe degradation may occur when network heavily loaded;
- processes run slower as they wait form required data ( that different processes must exchange)
- stress testing- helps to discover when degradation begins ( add checks to that point and reject transactions beyond this point);
Development testing-> responsibility of dev. team ,
separate team should be responsible for testing a
system before it is released to the customer,
customer/system users provide the test data and checks
if results are correct (end user training may be required)
User Testing
1. Alpha testing:
-users work with dev. team to test the software at dev. site
- XP (Agile) may not have acceptance testing as alpha testing users part of dev. team / available on the site
2. Beta testing:
- release is made available to users to allow them to experiment ans raise the problems discovered to the dev. team;
- early version evaluation;
public release -> shrink -wrapped systems (can be custom sys)
- marketing reasons
3. Acceptance testing:
- customer test the system to decide whether or not it is ready to be accepted from the dev. team and deployed in the cust environment.
How to run Acceptance tests? (6 STAGES)
1. Define acceptance criteria ( system contract).
2. Plan AT (resource, time, budget).
3. Derive AT (test funct. & on-funct.
requirements.
4. Run AT
5. Negotiate test results.
6. Reject/accept the system.
TDD- Test Driven Development
- Benefits

Run tests each time functionality is added OR refactor the code
- Provides understanding = easier to write required code
- Help programmers to clarify their ideas of what code segment is actually supposed to do
- Reduces the cost of REGRESSION TESTING
- AUTOMATION ( JUnit -> Java)
- Improves code quality...
1. CODE COVERAGE
Every code segment = assoc. test (code has been executed)
Code is tested as its written = defects discovered early in dev process.
2. REGRESSION TESTING
Test suite is developed incrementally as a program is developed. At any time regression test can be run to check if changes did or not introduced new bugs.
3. SIMPLIFIED DEBUGGING
When a test fails = easy to see where the problem is. The newly written code needs to be checked and modified. Debugging tools do not need to be used to locate the problems. Automated debugging not necessarily have to be used in TDD.
4. SYSTEM DOCUMENTATION
Tests act as a form document that describe what the code should be documented. Reading the tests can make it easier to understand the code.
REGRESSION TESTING
-involves running test sets that have successfully executed after changes have been made to a system.
- checks that these changes have not introduced new bugs/new ode interacts as expected with the existing code.
TDD- Test Driven Development
STEPS
1. Identify increment of functionality required (small/ to be implemented in few lines of code).
2. Write test for the functionality & implement this as automated test (test executed - > reports pass or fail)
3. Run the test with other tests implemented (it may fail if the functionality is not there).
4. Implement the functionality and re-run the test ( may involve code refactoring to improve
5. Once the tests run successfully you move on to implementing the next chunk of functionality.
TDD is mainly used for small- medium projects

TDD not used for:
- large legacy systems when large components of that system are reused = tests need to be written for the whole system.
- may not be effective with multi-threaded system (different threads may be interleaved at different times in different test runs -> may produce different test results).
Issues
Characteristics
DS Architectural
patterns

Two-tier client-server architecture
- is used for simple client-server
systems, and where the system is centralized for security reasons.

Multi-tier client-server architecture
- is used when there is a high
volume of transactions to be processed by the server.
Master-slave architecture
used in real-time systems in which
guaranteed interaction response times are required.
Distributed component
architecture;
- is used when resources from
different systems and databases need to be combined, or as an
implementation model for multi-tier client-server systems.
- require middleware to handle
component communications
& to allow components to be
added to and removed from the system.
Peer to-peer architecture; which is used when clients exchange locally
stored information and the role of the server is to introduce clients to each other
is a way of deploying applications as thin client- server systems, where the client is a web browser.
SaaS- Software as a service
Key Elements of Saas:
- ways of organizing the architecture of a distributed system
Inter-
dependent
- Denial of service (DoS) attacks on a system are intended to make it unavailable.
- Include recovery mechanisms to help restore normal system service after a failure
(fault-tolerance).
Dependability
- increased testing and system validation that is required to convince the system client and regulators that the required levels of dependability have been achieved.
e.g. Availability of 0.999 = system is up and
running for 99.9% of the time.
This number does not cover: number of user affected by the system outage and the length of the outage.
- can only be defined formally with respect to a system specification i.e. a failure is a deviation from a specification
a set of related ‘non-functional’ system attributes:
availability, reliability, safety and security.

System error-
erroneous system state that can lead to system behavior that is unexpected by system users.
System fault -
A characteristic of a software
system that can lead to a system error.
Failure &
Errors
Human error/mistake-
Human behavior that results
in the introduction of faults
into a system.
Fault avoidance -
Development technique are used that either minimise the possibility of mistakes or trap mistakes before they result in the introduction of system faults.

Fault detection and removal-
Verification and validation techniques that increase the
probability of detecting and correcting errors before the system
goes into service are used.

Fault tolerance-
Run-time techniques are used to ensure that system faults do
not result in system errors and/or that system errors do not lead
to system failures.
Dependability is compromised if a system is insecure as
the code or data may be corrupted.
Reliability achievement
Safety and reliability are related but distinct.
In general, reliability and availability are necessary but not sufficient conditions for system safety
Reliability is concerned with conformance
to a given specification and delivery of service
Safety is concerned with ensuring system cannot cause damage irrespective of whether or not it conforms to its specification.
Hazard avoidance
The system is designed so that some classes of hazard simply cannot arise.

Hazard detection and removal
The system is designed so that hazards are detected and
removed before they result in an accident.

Damage limitation
The system includes protection features that minimise the
damage that may result from an accident.
Safety Achievement
Hazard severity
An assessment of the worst possible damage that could result from a particular hazard.
Accident (or mishap)- an unplanned event or sequence of events which results in human death or injury, damage to property, or to the environment.
Hazard - a condition with the potential
for causing or contributing to an accident.
Damage - a measure of the loss resulting from a mishap. Damage can range from many people being killed as a result of an accident to minor injury or property damage.
Risk - This is a measure of the probability that the system will cause an accident. The risk is
assessed by considering the hazard probability, the hazard severity, and the probability that the hazard will lead to an accident
Hazard probability
The probability of the events occurring which create a hazard. Range 1/100.
As most systems are networked so
that external access to the system through the Internet is
possible.
Essential attribute
of the system
A pre-requisite for availability,
reliability and safety.
Terminology
Something of value which has to be protected. The asset may be the software
system itself or data used by that system.
Possible loss or harm to a computing system.
- loss or damage to
data, or loss of time and effort if recovery is necessary after a security breach.
A weakness in a system that may
be exploited to cause loss or harm.
An exploitation of a system’s vulnerability.
Generally, this is from outside the
system and is a deliberate attempt
to cause some damage.
Circumstances that have potential to cause loss or harm. -system vulnerability that is subjected to an attack.
- May refer to system or data:
confidentiality (authorization & access levels)
integrity (damage or corruption of the system data)
or availability (access restrictions)
is an example of a control that reduces a vulnerability of a weak access control system.
Security Assurance
Exposure limitation and recovery
The system is designed so that the adverse consequences of successful attack are minimised. E.g., a backup policy
allows damaged information to be restored.
Disclosure of confidential information
Information that is managed by the system may be exposed to people who are not authorised to read or use that information.
- the ability of the system to protect itself and its data from external interference;
Essential
software product attributes:
- maintainability;
- dependability;
- security;
- efficiency;
- acceptability;
Software=
program/s + documentation
What are the attributes of
good software
?
- deliver the required functionality;
- deliver the required performance to the user;
- and should be:
maintainable, dependable and usable.
Fundamental software engineering activities?
software specification, software development, software validation and software evolution.
Fundamental ideas of SE:
- managed software process; - software dependability
and security;
- requirements engineering;
- software reuse.
Application Types
SE diversity:
different types of
software system = no universal set of software techniques that is
applicable to all of these.
Stand-alone applications
§ run on a local computer,
such as a PC they include all necessary functionality and do not need to be connected to a network.
Batch processing systems
§ designed to process data
in large batches,process large numbers of individual inputs to create corresponding outputs.
Data collection systems
§ collect data from their environment using a set of sensors and send that data to other systems for processing.
Interactive transaction-based applications
§ execute on a remote computer and are
accessed by users from their own PCs or terminals. Web applications such as e-commerce.
Embedded control systems
§ software control systems that control and manage hardware devices; more embedded systems than any other type of system.
Systems of systems
§ composed of a number of other software systems.
Systems for modeling and simulation
§ systems that are developed by scientists and engineers to model physical processes or situations, include many, separate, interacting objects.
Entertainment systems
§ primarily for personal use and which
are intended to entertain the user.
Software costs more to maintain
than it does to develop.
For systems with a long life,
maintenance costs may be
several times development costs.
SE is concerned with cost-effective
software development.
§ Stand-alone systems- marketed and sold to any
customer who wishes to buy them, e.g. PC software such as graphics programs, project
management tools; CAD (computer-aided-design) software; software for specific markets such as appointments systems for dentists.




Customized products
§ Software that is commissioned by a specific customer to meet their own needs, e.g.embedded control systems, air traffic control
software, traffic monitoring systems.
Software Engineering
fact sheet
Cheaper, in the long run,
to use software engineering methods and techniques for software systems
rather than write the programs
as if it was a personal programming project.
General Issues that affect most software
Web software engineering

Software reuse is the dominant approach for constructing web-based systems.

When building these systems, you think about how you can assemble them from pre-existing software components and systems.

- should be developed and delivered
incrementally.

-it is impractical to specify all the
requirements for such systems in advance.

- User interfaces are constrained by the capabilities of web browsers.

- Technologies such as AJAX allow rich interfaces to be created within a web browser but are still difficult to use. Web forms with local scripting are more commonly used.
Software engineers must behave in an honest and
ethically responsible way if they are to be respected as professionals.
Ethical behaviour is more than simply upholding the law but involves following a set of principles that are morally correct.
Generic Products
Software Engineering
& the Web
The Web = a platform for running applications.
Organizations are increasingly developing web-based systems rather than local systems.
Web services - allow application
functionality to be accessed over the web.

Cloud computing is an approach to the provision of
computer services where applications run remotely on the ‘cloud’.
The majority of costs = the costs of changing the
software after it has gone into use.
SE Issues
Heterogeneity
Increasingly, systems are required to operate as distributed systems across networks that include different types of computer and mobile devices.
Business and social change
Business and society are changing incredibly quickly as emerging economies develop and new technologies become
available. They need to be able to change their existing software and to rapidly develop new software.
Security and trust
As software is intertwined with all aspects of our lives, it is essential that we can trust that software.
Confidentiality, Competence,
Intellectual Property Rights,
Computer Misuse.
Professional
responsibility:
STRESS TESTING
- tests the failure behaviors of the system;
- stresses the system & may cause defects to come to light that would normally not be discovered;
Types
Stress Testing
ADDITIONAL BENEFITS:
Dependencies
- A system may be unreliable because its data has been corrupted by an external attack.
- Safe system operation depends on the system being available and operating reliably.
- If a system is infected with a virus, you cannot be confident in its reliability or safety.
Increased system dependability = higher cost,
due to:
Dependability
vs Cost
- use of more expensive development techniques.
- hardware that are required to achieve the higher levels of dependability.
Dependability Achievement
- Avoid the introduction of accidental errors when
developing the system.
- Design V & V processes that are effective in discovering residual errors in the system.
- Design protection mechanisms that guard against
external attacks.
- Configure the system correctly for its operating
environment.
The ability of the system to operate without catastrophic failure
Vulnerability avoidance
The system is designed so that vulnerabilities do not occur.
E.g., if there is no external network connection then external attack is impossible.
The system is designed so that attacks on vulnerabilities are detected and neutralised before they result in an exposure.
E.g. virus checkers find and remove viruses before they infect a system.
Denial of service (DoS)
The system is forced into a state where normal services are unavailable or where service provision is significantly degraded.
The programs or data in the system may be modified in an unauthorised way.
Corruption of programs or data
Attack detection and elimination
Security -
Asset
Vulnerability
Attack
Exposure
Threats
Control
A protective measure that reduces a system’s vulnerability.
Encryption
Diversity
Provide the same functionality in different ways so that they will not fail in the same way.
-avoiding the introduction of faults, by detecting and removing faults before system deployment, and by including fault tolerance facilities.
- designed for fault tolerance.
- architectural styles that support fault
tolerance include protection systems, self-monitoring architectures and N-version programming.
Dependability
Engineering

Redundancy
Keep more than 1 version of a critical component available so that if one fails then a backup is available.
Adding diversity and redundancy adds
complexity and this can increase the chances of error.
Some engineers advocate :
simplicity and extensive V & V is a more effective route to software dependability.
Dependable system architectures
Best Practices
Rather, multiple different process activities the
complement each other and allow for cross-checking
help to avoid process errors, which may lead to errors in the software.
Dependable Processes
Attributes
Well-defined, repeatable process
helps to ensure a minimal number of software faults:
- does not depend entirely on individual skills, rather can be enacted by different people.
- regulators use information about the
process to check if good software engineering practice has been used.
- for fault detection, it is clear that the
process activities should include
significant effort devoted to verification
and validation.
- requirements reviews,
- requirements management,
- formal specification,
- system modeling,
- design and code inspection,
- static analysis,
- test planning and management,
- change management.
Process characteristic & Description
Robust
The process should be able to recover from
failures of individual process activities.
Diverse
The process should include redundant and
diverse verification and validation activities.
Auditable
The process should be understandable by people
apart from process participants, who can check
that process standards are being followed and
make suggestions for process improvement.
Standardized
A comprehensive set of software development
standards covering software production and
documentation should be available.
Documentable
The process should have a defined process
model that sets out the activities in the process
and the documentation that is to be produced
during these activities.
Process diversity and redundancy
Process activities, such as validation,
should not depend on a single approach, such as testing, to validate the system.
Validation activities:
- the use of redundancy and diversity in hardware, software processes and software systems is essential for the development of dependable systems.
- the use of a well-defined, repeatable process is essential if faults in a system are to be minimized.
Security management
concerned with infrastructure
Security engineering
concerned with applications
Tools, techniques and methods to support the
development and maintenance of systems that can resist malicious attacks that are intended to damage a computer-based system or its data.
Application security = a software engineering problem, where the system is designed to resist attacks.
Infrastructure security = a systems management problem where the infrastructure is configured to resist attacks.
Attack monitoring, detection and recovery
Monitoring the system for unauthorized access, design strategies for resisting attacks and develop backup and recovery
strategies.
User and permission management
- Adding and removing users from the system and setting up appropriate permissions for users
Software deployment and maintenance
Installing application software and middleware and configuring these systems so that vulnerabilities are avoided.
Security Engineering
Design Guidelines
for Security
Design so that deployment problems that
may introduce vulnerabilities are minimized
 When systems fail, ensure that sensitive information cannot be accessed by unauthorized users even although normal security procedures are unavailable.
 Define a security policy for the organization that sets out the fundamental security requirements that should apply to all organizational systems.
 Ensure that a security failure can only result when there is more
than one failure in security procedures.
Maintain a log of user actions that can be analyzed to discover who did what.
Try to avoid security procedures that make the system difficult to use.
Keep multiple copies of data and use diverse infrastructure so that an infrastructure vulnerability cannot be the single point of
failure.
Compartmentalize your assets
Organize the system so that assets are in separate areas and users only have access to the information that they need rather than all system information.
Base decisions on an explicit security policy
Fail securely
Avoid a single point of failure
Balance security and usability
Log user actions
Use redundancy and diversity to reduce risk
Validate all inputs
Check that all inputs are within range so that unexpected inputs cannot cause problems.
Design for recoverability
To simplify recoverability after a successful attack.
Design for deployment
To avoid deployment problems
- assessing the possible losses that might ensue from attacks on the system and balancing these losses against the costs of security procedures that may reduce these losses.
Security
Risk Management
- should be driven by an organisational security policy.
Access to the system shall only be allowed by approved client computers.
Security Requirements
A password checker shall be made available and shall
be run daily. Weak passwords shall be reported to
system administrators.
All client computers shall have a single, approved web browser installed by system administrators.
Introduction
Virtually all large computer-based systems are now distributed systems.
Distributed software engineering is therefore very
important for enterprise computing systems.
Information processing is distributed over several
computers rather than confined to a single machine.
“… a collection of independent computers that appears to the user as a single coherent system.”
Distributed systems are more complex than systems that
run on a single processor.
Complexity arises because different parts of the system
are independently managed as is the network.
There is no single authority in charge of the system so
top-down control is impossible.
Resource sharing
Sharing of hardware and software resources.
Openness
Use of equipment and software from different vendors.
Concurrency
Concurrent processing to enhance performance.
Fault tolerance
The ability to continue in operation after a fault has occurred.
Scalability
How can the system be constructed so that it is scaleable?
Transparency
To what extent should the distributed system appear to the user as a single system?
Openness
Should a system be designed using standard protocols
that support interoperability?
Failure management
How can system failures be detected,
contained and repaired?
Quality of service
How should the quality of service be specified.
Security
How can usable security policies be defined and
implemented?
Denial of service attacks involve bombarding a node with illegitimate service requests so that it cannot deal with valid requests.
Client-server architecture
- structured into layers,
- the user interacts with a program running on their local computer (e.g. a web
browser or phone-based application).
This interacts with
another program running on a remote computer (e.g. a
web server).
The benefits of distributed systems are that they can be scaled to cope with increasing demand, can continue to provide user services if parts of the system fail, and they enable resources to be shared.
Users may pay for the software according to the amount of use they make of it or through an annual or monthly subscription. (may be free if users wish to accept advertisements)
The software is owned and managed by a software
provider, rather than the organizations using the
software
Accessed through a web browser, (It is not deployed on a local PC)
Software is deployed on a server (or more commonly a number of servers)
- is an approach to structuring a software system as a set of separate, stateless services.
These may be provided by multiple
providers and may be distributed.
Typically, transactions are short transactions where a service is called, does something then returns a result.
Service-oriented
architecture (SOA)

Software
Processes

Introduction
A structured set of activities required to
develop a software system.
- Evolution – changing the system in response to changing customer needs.
Process descriptions may also include:
Plan-driven processes
are processes where all of the
process activities are planned in advance and progress is measured against this plan.
General Process Models:
- waterfall model;
- incremental development,
- reuse oriented engineering.
Products, which are the outcomes of a process activity;
Pre- and post-conditions, which are statements that are true before and after a process activity has been enacted or a product produced.
Roles, which reflect the responsibilities of the people involved in the process;
All software processes involve:
- Specification – defining what the system should do;
- Design and implementation – defining the organization of the system and implementing the system;
- Validation – checking that it does what the customer wants;
In
agile processes
, planning is incremental and it is
easier to change the process to reflect changing
customer requirements.
In practice, most practical processes include elements of both plan-driven and agile approaches.
There are no right or wrong software processes.
The Rational Unified Process (RUP)
- is a modern generic process model;
- organized into phases (inception, elaboration, construction and transition)
but separates activities (requirements, analysis and design, etc.) from these phases.
Processes may be structured for iterative development and delivery so that changes may be made without disrupting the system as a whole.
Processes should include activities to cope with change. This may involve a prototyping phase that helps avoid poor decisions on requirements and design.
Software Process Activities
2.Working software over comprehensive documentation
3. Customer collaboration over contract negotiation
4. Responding to change over following a plan
Scrum project management approach
The aim of agile methods is to reduce overheads in the software process (e.g. by limiting documentation) and to be able to respond quickly to changing requirements without excessive rework.
Agile Manifesto
XP Programming (Extreme programming)
-pair-programming,
-test-first development,
-simple design,
- small releases,
- refactoring.
System building
The process of assembling program components, data and libraries,
then compiling these to create an executable system.
Change management
Keeping track of requests for changes to the software from customers and developers, working out the costs and impact of changes, and deciding the changes should be implemented.
Version management
Keeping track of the multiple versions of system components and ensuring that changes made to components by different developers do
not interfere with each other.
Release management
Preparing software for external release and keeping track of the system versions that
have been released for customer use.
Types of attack in
a distributed system

Interception, where communications between parts of the system are intercepted by an attacker so that there is a loss of confidentiality.
Fabrication, where an attacker generates information that should not exist and then uses this to gain some privileges.
Modification, where data or services in the system are changed by an attacker.
Interruption, where system services are attacked and cannot be delivered as expected.
Full transcript