overview of 219341 software specification and design
Download
Skip this Video
Download Presentation
Overview of 219341: Software Specification and Design

Loading in 2 Seconds...

play fullscreen
1 / 65

Overview - PowerPoint PPT Presentation


  • 210 Views
  • Uploaded on

Overview of 219341: Software Specification and Design. What We Want. Need or Idea. Software. source: Bruegge, Object-oriented Software Engineering. Why can\'t we just write the program?. The Problem.

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Overview' - KeelyKia


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
what we want
What We Want

Need or Idea

Software

source: Bruegge, Object-oriented Software Engineering

the problem
The Problem

"Programming is fun, but developing quality software is hard. In between the nice ideas, the requirements or the "vision", and a working software product, there is much more than programming.

Analysis and design, defining how to solve the problem, what to program, capturing this design [...], review, implement, and evolve is what lies in the core of this book."

[Forward to textbook by Philippe Kruchten]

intrinsic complexity of software
Intrinsic Complexity of Software

About the future of software development...

"There is no singledevelopment, in either technology or in management technique, that by itself promises even one orderofmagnitude improvement in productivity, in reliability, in simplicity."

"No Silver Bullet" by Frederick Brooks. Computer, 1987

See also page 5-6 for Brooks comments about object-oriented approach.

topics covered in this course
Topics Covered in this Course
  • The Software Development Process and Life Cycle Models
  • Software Process for Requirements and Design
  • Iterative & Evolutionary Approach to Software
    • Emphasis on Analysis, Specification, and Design
specific topics 1
Specific Topics (1)
  • Creating a Vision
  • Discovering and Documenting Requirements
  • Analysis and Modeling
    • Analyze Requirements
    • Domain Modeling
    • Implementation Modeling
    • UML as visual modeling tool
  • Documentation: project, process, and many others
specific topics 2
Specific Topics (2)
  • Design a solution
    • Principles to guide design decisions
    • Design Patterns
  • Iteratively implementing and refining requirements
  • Validation: testing and reviews
  • Risk as key to avoiding project failure
  • Technology & Tools
    • issue tracking
    • version control
    • documenting change and rationale
patterns and standards
Patterns and Standards
  • We use Patterns to...
    • apply knowledge learned by others, avoid mistakes
    • don\'t rediscover what is already known
    • "knowledge reuse"
  • We use Standards to...
    • apply software process knowledge learned by others
    • avoid omissions and mistakes
    • make projects more repeatable and predictable
    • recipes for "best practices"
where does this course fit in
Where Does This Course Fit In?
  • Software Specification & Design
  • Software Verification & Validation
  • Software Testing
  • Project Management
  • Software Processes & Quality Assurance
  • Economics of Software
  • OOP
  • Database, Networking
  • Algorithms & Data Structures
workflows
Workflows

Core

Process

Workflows

Supporting

Workflows

imagine you have a software idea
Imagine You Have a Software Idea...

Scenario:

  • You are part of a small to medium size software company.
  • You have an idea for a great software product.

What Do You Do?

  • How do you turn your idea into a project?
  • What are the steps?

How Will Your Idea Become A Software Project and a Software Product?

textbooks and readings
Textbooks and Readings

Required Textbook:

Craig Larman, Applying UML and Patterns : An Introduction to Object-Oriented Analysis and Design, 3rd Edition, P-H

Strengths:

  • Excellent for O-O Analysis and Design
  • Emphasizes iterative development
  • Author conveys real-world experience

Weaknesses:

  • Fuzzy about documents and how docs fit together.
  • Bias towards Agile methods; fuzzy about what is a software process.
  • Some gaps you have to research for yourself.
useful books and resources
Useful Books and Resources
  • Martin Fowler, UML Distilled, 3rd Ed. E-book available.
  • Booch, Jacboson, Rumbaugh, The Unified Modeling Language User Guide, 2nd Ed. (more material, but harder to read)
  • Blaha & Rumbaugh, Object-Oriented Modeling and Design with UML, 2nd Ed. Detailed, good insights, but very dense reading.
  • Bruegge & Detoit, Object-Oriented Software Engineering
  • Lethbridge & Laganiere, Object-Oriented Software Engineering, 2nd Ed. (easy to read, good intro to framework concept)
  • Other readings will be assigned from the literature.
requirements
Requirements
  • Read the assigned material before class each week.
  • Take notes: summarize important points.
  • Participate in discussions.
  • Group project
    • individual roles
    • everyone is developer. everyone is "programmer"
  • Evaluation: exams and quizzes
project
Project
  • Must have a real client
  • Must have a concrete, realistic objective
  • Approved by me
tentative projects
Tentative Projects
  • Program to count stock (inventory) for KU Bookstore.

Client: KU Bookstore

Requirements: I don\'t know

  • LDAP (directory service) web client for CPE.

Client: me, Aj. Anan

Requirements: user can view and edit his own profile, change password, search for other people

  • Journal article tracking for KU Engineering Journal.

Client: Aj. Pirayut, Jim (as proxy)

Requirements: submit articles online, track the progess of article

observations from an ske student
Observations from an SKE student...

Object-Oriented Programming

This is the most important part if we need to communicate with others in development team, more precisely diagram will ensure everybody agree on same goal, it decrease other problem and risk.

The OOP isn\'t necessary in detailed, but should focus to unite the concept which everyone understand.

I think drawing technique and communication skill is important here.  For design and analysis, OOP help real world developer, analysis, and system designer more precisely on their task. Many diagrams may be raised in discussion but finally, we got only few \'solid\' diagram which team use to implement, or for next discussion.

observation from ske students
Observation From SKE Students...

From SKE students now working in companies...

  • The most important factor for software projects is communication.
  • Imprecise communication leads to many misunderstandings and errors.
  • Visual modeling is helpful for communication.
  • UML diagrams must be accurate to be useful.
  • Lack of documentation makes project more difficult.
software processes why
Software Processes... why?
  • Imagine you are a seniorsoftware engineerat SiamSoft.
  • A person from the sales department comes to you with a custom software project they want to bid on...
software processes why22
Software Processes... why?

Product Description:

  • A web-based system for buying and selling used electronics, books, cars, CDs, motorcycles, and other items.
  • Registered sellers can login and post item descriptions with digital photos, and price of the item. Items are placed in categories.
  • Anyone can browse available items, but must login in order to buy something.
  • All transactions are cleared through our system, which charges a commission of 4% of the sales price (commission may be changed and may use a sliding scale: lower for high-cost items and frequent sellers).
  • Buyers and sellers can "rate" each other, log complaints, track orders (very limited), and cancel orders (with restrictions).
  • The system must remove "sold" items, cancelled, or old items.
  • This system must be secure.
software processes why23
Software Processes... why?

The sales person\'s questions for you are simple:

How much will it cost to build this?

How long will it take?

What personnel (and how many) do you need?

  • Discussion Question:

How would you go about answering these questions?

Remember, you\'re a senior software engineering who has worked on other projects at this company.

software processes why24
Software Processes... why?

Approaches to answering these questions:

  • look for similar projects your company has done. Use the project data from those.
  • do a rough, high-level architecture design.Then estimate the cost/manpower for each component.
  • apply a cost estimation method such as COCOMO. This may require some preliminary software design.
  • ask an expert......uh, I forgot. youare the expert.
difficulties
Difficulties
  • Client\'s requirements are not fully known
    • may have non-functional requirements
    • example: require use of a particular database or hardware platform (that you\'re staff doesn\'t know)
    • can you identify a non-functional constraint in the description
  • Previous results may not be repeatable
    • if projects are managed ad hoc
    • if organization depends on a few skilled or charismatic individuals
your goals as software professionals
Your Goals as Software Professionals
  • Work for Google.
  • Want to develop useful software that helps the client or user.
  • Want to write/design good quality software that lasts.
  • Make a living (profit) by doing this.
realities of software
Realities of Software
  • Obstacles to writing good software.
  • Change.
  • Useful software is complex.
  • Communication - don\'t clearly understand what the user(s) want. They don\'t understand us.
topics
Topics
  • Software process models
  • Process iteration
  • Software specification
  • Software design and implementation
  • Software validation
  • Software evolution
  • Automated process & project support
what we want29
What We Want

Need or Idea

Software

source: Bruegge, Object-oriented Software Engineering

real world software lifecycle
Real World Software Lifecycle
  • a need or an idea
  • explore and understand what is needed
  • a vision and business case for the project
  • decision to implement or drop
  • initial prototype.
  • discover more requirements
  • reimplement in greater detail
  • software + architecture design
  • working but buggy software
  • software initial release for use
  • iterative fix bugs and add new features
what is a life cycle model
What is a Life Cycle Model
  • A model of the phases that software goes through
  • Serves as a guide for management of software development
  • Model is an abstraction.
    • omits some real-life complexity and detail
typical lifecycle model
Inception of idea

vision

business case

Analysis

Design

Implementation

Acceptance

Deployment

transition

training & education

Typical Lifecycle Model
  • Maintenance and Support
  • End of Support
  • Retirement
    • end of useful life
    • transition or archiving

GREEN = part of the process, not life cycle

is testing part of the software lifecycle
Is Testing Part of the Software Lifecycle?
  • Many people say it is.
  • Or,is testing an activity that is part of many steps in the lifecycle?
how it should go our plan of attack

Requirements

Analysis

Design

Implementation

Testing

Delivery and Installation

How it should go: Our plan of attack

source: Bruegge, Object-oriented Software Engineering

why this model doesn t work
Why this Model Doesn\'t Work
  • Requirements aren\'t complete or accurate.
    • even the client doesn\'t know precisely
  • Analysis and design aren\'t accurate.
    • communication issues
    • model not precise
  • Difficult to manage change...
    • technology changes
    • new requirements emerge
    • resource limitations
  • Software consists of many systems
code and fix
Code-and-Fix

Client

Requirements

repeat as needed

Code

[fail]

Test

[pass]

[fail]

Client Acceptance

[pass]

This is the implicit process for software development without any formal process model.

Delivery &

Maintenance

linear development

Requirements

Analysis

Design

Implementation

Acceptance Test

Linear Development
  • determine requirements for the product
  • analysis requirements to create a specification.
  • use the specification to construct a software design to satisfy it
  • build it
  • acceptance test by client, followed by delivery and maintenance

Delivery and Maintenance

waterfall model

Requirements

Analysis

Design

Implementation

Acceptance Test

Waterfall Model

The waterfall model recognizes that an activity may uncover a problem from a previous phase.

A previous phase must be reworked to make necessary modifications. This may in turn uncover a problem from its predecessor (i.e. going uphill again).

Delivery and Maintenance

waterfall loopback in reality

Requirements

Analysis

Design

Implementation

Acceptance Test

Waterfall Loopback in Reality

Royce (1970) found that backtracking multiple phases was usually necessary.

The most common backtracking is as shown.

Delivery and Maintenance

evolutionary development

Requirements1

Analysis1

Design1

Requirements3

Analysis3

Design3

Evolutionary Development

Episode 1

Episode 2

Episode 3

. . .

. . .

Implementation1

Implementation2

Implementation3

Each episode attempts to build a complete product, but the process recognizes the need to repeat the process (in all or part). See Schach, section 2.1.

iterative and incremental
Iterative and Incremental
  • A two-dimensional model: workflows of each increment can overlap.
miller s law
Miller’s Law
  • At any one time, a person can concentrate on at most 7  2chunks (units of information)
  • To handle larger amounts of information, use stepwise refinement
    • Concentrate on the aspects that are currently the most important
    • Postpone aspects that are currently less critical
    • Every aspect is eventually handled, but in order of current importance
  • This is an incremental process
the cost of change
The Cost of Change

The cost of detecting and correcting a fault at each phase

Figure 1.5

the cost of change44
The Cost of Change

The previous figure redrawn on a linear scale

Figure 1.6

incremental development
Incremental development

This slide is from Sommerville, Software Engineering.

Do you agree with the activities and flow lines?

incremental development advantages
Incremental development advantages
  • System functionality is available earlier
  • Customer sees value added at each increment
  • Early increments act as a prototype to help elicit requirements for later increments
  • Discover design changes and problems early
  • Lower the risk of overall project failure
  • Highest priority system services tend to receive the most testing
classical phases versus workflows
Classical Phases versus Workflows
  • Sequential phases do not exist in the real world
  • Instead, the five core workflows (activities) are performed over the entire life cycle
    • Requirements workflow
    • Analysis workflow
    • Design workflow
    • Implementation workflow
    • Test workflow
  • Question: why there is a separate test workflow?
workflows48
Workflows
  • All five core workflows are performed over the entire life cycle
  • However, at most times one workflow predominates
  • Examples:
    • At the beginning of the life cycle
      • The requirements workflow predominates
    • At the end of the life cycle
      • The implementation and test workflows predominate
  • Planning and documentation activities are performed throughout the life cycle
iteration and incrementation contd
Iteration and Incrementation (contd)
  • For example increment A
    • Determine the requirements
    • After most the requirements have been determined, the first version of the analysis starts
    • Then design
    • Some coding is done
    • Proof-of-concept testing
  • Planning, testing, documentation start on day one
iteration and incrementation cont d
Iteration and Incrementation (cont\'d)
  • Iteration is performed during each increment

Schach, Figure 2.5

iteration and incrementation cont d51
Iteration and Incrementation (cont\'d)
  • The number of iterations will vary—it is not always three or four
  • Usual goals:
    • keep iteration duration < 8 weeks
    • add new requirements (e.g. use cases) at each iteration
    • start with the most important use cases
incorporating risk
Incorporating Risk
  • Software development involves risks
    • developer may not be able to complete product according to spec
    • may not be able to meet deadline or budget
    • technology changes
    • personnel may quit, die, ...
    • another product may render the software unmarketable
  • Risk analysis is a part of each phase of a project
  • Minimizing risk can effect design choices
classical phases vs object oriented workflows
Classical Paradigm

Requirements phase

Analysis (Specification) phase

Design phase

Implementation phase

Post-delivery maintenance

Retirement

Object-Oriented Paradigm

Requirements workflow

O-O Analysis workflow

O-O Design workflow

O-O Implementation workflow

Post-delivery maintenance

Retirement

Classical Phases vs Object-Oriented Workflows

There is no correspondence between phases and workflows.

analysis design hump
Analysis/Design “Hump”
  • Structured paradigm:
    • There is a jolt between analysis (what) and design (how)
  • Object-oriented paradigm:
    • Objects enter from the very beginning
analysis design hump cont d
Analysis/Design “Hump” (cont\'d)
  • In the classical paradigm
    • Classical analysis
      • Determine what has to be done
    • Design
      • Determine how to do it
      • Architectural design — determine the modules
      • Detailed design — data structure and algorithms of each module
removing the hump
Removing the “Hump”
  • In the object-oriented paradigm
    • Object-oriented analysis
      • Determine what has to be done
      • Determine the objects
    • Object-oriented design
      • Determine how to do it
      • Design the objects
  • The difference between the two paradigms is shown on the next slide
object oriented approach
Classical Paradigm

Requirements phase

Analysis (Specification) phase

Design phase

Implementation phase

Post-delivery maintenance

Retirement

Object-Oriented Paradigm

Requirements workflow

O-O Analysis workflow

O-O Design workflow

O-O Implementation workflow

Post-delivery maintenance

Retirement

Object-Oriented Approach

Objects enter here

object oriented paradigm
Object-Oriented Paradigm
  • Modules (objects) are introduced as early as the object-oriented analysis workflow
    • This ensures a smooth transition from the analysis workflow to the design workflow
  • The objects are then coded during the implementation workflow
    • Again, the transition is smooth
  • OO is an integrated approach
    • Reduce number of faults introduced in the development
3 1 the unified process
3.1 The Unified Process
  • Three of the most successful object-oriented methodologies in the 1990s were:
    • Booch’s method
    • Jacobson’s Objectory
    • Rumbaugh’s OMT
the unified process cont d
The Unified Process (cont\'d)
  • Gradually Booch, Jacobson, and Rumbaugh combined, unified, their methods. All three ended up at Rational, a company that marketed SE development products.
  • In 1999, Booch, Jacobson, and Rumbaugh published a object-oriented analysis and design methodology that unified their three separate methodologies:

The Unified Software Development Process

  • Other names : Rational Unified Process (RUP), Unified Process (UP),OpenUP (a new, lighter weight version)
the unified process cont d62
The Unified Process (cont\'d)
  • The Unified Process is not a series of steps for constructing a software product
    • No single “one size fits all” methodology exists
    • There is a wide variety of different types of software
  • The Unified Process is an adaptablemethodology
    • It has to be modified for the specific software product to be developed
the unified process
The Unified Process
  • is...
    • use-case driven
    • architecture centric
    • iterative
    • incremental
    • object-oriented, usually
  • a multi-dimensional model
    • workflows
    • iterations
workflows64
Workflows

Core

Process

Workflows

Supporting

Workflows

what about this course
What about this course?
  • The workflows:
    • requirements
    • analysis
    • design
    • implementation
    • testing
    • configuration management
    • project management
    • environment (tools)
    • deployment

emphasis in here

but we also do these

ad