review se
Post on 13-Jan-2015
482 Views
Preview:
DESCRIPTION
TRANSCRIPT
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
top related