Your SlideShare is downloading. ×
Review se
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Review se

504
views

Published on

homework

homework

Published in: Education

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
504
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
7
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Review 12/11/09
  • 2. 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
  • 3. 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
  • 4. 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
  • 5. 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
  • 6. 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
  • 7. 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
  • 8. 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!
  • 9. 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
  • 10. 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
  • 11. 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.
  • 12. System Requirements
    • What system should do?
      • Functional Requirements
      • System Properties (Non functional emergent properties)
      • Characteristics what system shouldn’t do (limitations of the system)
  • 13. 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
  • 14. 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
  • 15. Dimensions of dependability
  • 16. Costs of increasing dependability
  • 17. 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
  • 18. 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
  • 19. 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
  • 20. 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
  • 21. Evolutionary development
    • More 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
  • 22. 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
  • 23. 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
  • 24. Process iteration
    • System requirements always evolve in the course of a project
    • Two kind of iterative process models
      • Incremental development
      • Spiral development
  • 25. 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
  • 26. 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
  • 27. 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
  • 28. Spiral model of the software process
  • 29.
    • 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
  • 30.
    • 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
  • 31. 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
  • 32. 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
  • 33. Task durations and dependencies
  • 34. Activity network Critical Path: The minimum time required to finish the project (i.e the longest path in the activity graph)
  • 35. Activity timeline – Gantt chart
  • 36. 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
  • 37. 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
  • 38. Risk identification
    • Technology risks
    • People risks
    • Organisational risks
    • Requirements risks
    • Estimation risks
  • 39. 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
  • 40. 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
  • 41. 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
  • 42. 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
  • 43. 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.
  • 44. 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
  • 45. 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
  • 46. 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 .
  • 47. 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
  • 48. 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.
  • 49. Non-functional requirement types
  • 50. 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.
  • 51. 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.
  • 52. 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
  • 53. Requirements Engineering
    • Feasibility studies
    • Requirements elicitation and analysis
    • Requirements validation
    • Requirements management
  • 54. 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.
  • 55. 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.
  • 56. 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?
  • 57. 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.
  • 58. 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.
  • 59. 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.
  • 60. 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.
  • 61. 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)
  • 62. 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
  • 63. 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 Requirements
    • System Requirements
  • 64. 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 Case Diagrams Use Case Diagrams Use Case Diagrams Scenario Diagrams Scenario Diagrams Collaboration Diagrams State Diagrams State Diagrams Component Diagrams Component Diagrams Component Diagrams Deployment Diagrams State Diagrams State Diagrams Object Diagrams Scenario Diagrams Scenario Diagrams Statechart Diagrams Use Case Diagrams Use Case Diagrams Sequence Diagrams State Diagrams State Diagrams Class Diagrams Activity Diagrams Models
  • 65. Use Case Diagram Fig. 3-53, UML Notation Guide
  • 66. 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.
  • 67. The context of an ATM system
  • 68. 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.
  • 69. Equipment procurement process
  • 70. 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
  • 71. Library class hierarchy
  • 72. Object interaction (Sequence Diagram)
  • 73.  
  • 74. 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
  • 75.  
  • 76. 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
  • 78. Film and picture library
  • 79.  
  • 80.  
  • 81.  
  • 82. Layered Architecture Example :Version management system
  • 83.  
  • 84.