The Software Process - PowerPoint PPT Presentation

1 / 44
About This Presentation
Title:

The Software Process

Description:

Cheap option. Discard rapid prototype ... 20 flight records are stored in an array ... report on meals onboard the flight. other 4 reports are similar to the ... – PowerPoint PPT presentation

Number of Views:200
Avg rating:3.0/5.0
Slides: 45
Provided by: stephe594
Category:
Tags: process | software

less

Transcript and Presenter's Notes

Title: The Software Process


1
CHAPTER 10
REQUIREMENTS PHASE
2
Overview
  • Requirements elicitation
  • Requirements analysis
  • Rapid prototyping
  • Human factors
  • Rapid prototyping as a specification technique
  • Reusing the rapid prototype
  • Management implications of the rapid prototyping
    model
  • Experiences with rapid prototyping

3
Overview (contd)
  • Techniques for requirements elicitation and
    requirements analysis
  • Testing during the requirements phase
  • CASE tools for the requirements phase
  • Metrics for the requirements phase
  • Object-oriented requirements?
  • Air Gourmet case study Requirements phase
  • Air Gourmet case study Rapid prototype
  • Challenges of the requirements phase

4
Requirements Phase
  • Misconception
  • Must determine what client wants
  • I know you believe you understood what you think
    I said, but I am not sure you realize that what
    you heard is not what I meant!
  • Must determine clients needs

5
Requirements Analysis Techniques
  • Interviewing (primary technique)
  • Structured versus unstructured interviews
  • structured use specific, preplanned,
    close-ended questions
  • example ask client how many salespeople the
    company employs
  • or ask how fast a response time is required
  • unstructured open-ended questions
  • example why is the current product
    unsatisfactory?
  • need both types of questions

6
Requirements Analysis Techniques
  • Questionnaires
  • useful if have hundreds of individuals to
    question
  • can get well thought out answers
  • but only get what you ask for cannot uncover new
    problems.

7
Requirements Analysis Techniques
  • Forms analysis
  • look at forms currently being used
  • Video cameras
  • record people at work
  • takes a long time to analyze
  • often seen as invasion of privacy

8
Requirements Analysis Techniques
  • Scenarios
  • Story boards
  • Trees
  • Rapid prototyping

9
Requirements Analysis
  • two types of requirements
  • functional requirements.
  • example Royalties for each artist shall be
    computed from the playlist data using the May
    1998 CMS formula.
  • non-functional requirements.
  • specify properties of the target software
  • example reliability and maintainability
  • or relate to the environment in which the
    software must run
  • example all bar codes shall be read using the
    Mach/Zor ASRCA input device.

10
Requirements Analysis
  • Software must be traceable.
  • must be possible to trace each statement in the
    requirements document through the specifications,
    design, and code.
  • Allows SQA group to check that every statement in
    the requirements has been implemented correctly.
  • Thus each statement in the requireemnts document
    needs to be numbered.

11
Requirements Analysis
  • Client must rate each requirement
  • essential, highly desirable, desirable, etc.
  • requirements must be corrected as rest of process
    is done.
  • next a rapid prototype is built.

12
Rapid Prototyping
  • Hastily built (rapid)
  • Key functionality

13
Rapid Prototyping
  • Example apartment management software
  • requires input screen that allows user to enter
    details of a new tenant and print an occupancy
    report for each month.
  • These aspects must be included in the RP
  • Do not include error-checking, file-updating
    routines, and complex tax computations.

14
Rapid Prototyping
  • Rapid prototype reflects the functionality that
    the client sees
  • eg, screens and reports
  • omits hidden aspects such as file updating.

15
Rapid Prototyping
  • Client experiments with prototype
  • Developers watch and take notes.
  • Users relate what works and what is missing.
  • Developers change prototype until it meets client
    needs.

16
Rapid Prototyping
  • Prototype does not have to work perfectly.
  • Prototype must reflect the users view of the
    software.
  • Prototype must be easy to change.
  • Prototype is thrown away after it is used.

17
Human Factors
  • Client and intended users must interact with the
    user interface
  • Human-computer interface (HCI)
  • Menu, not command line
  • Point and click
  • Windows, icons, pull-down menus

18
Human Factors
  • Human factors must be taken into account
  • Lengthy sequence of menus every choice leads to
    yet another choice.
  • this is frustrating for a user.
  • must also allow a user to change a previous menu
    without going all the way back to the top-level
    menu.
  • Expertise level of interface
  • if users have different levels of expertise, must
    provide different sets of interfaces or a single
    interface that can be modified by users.

19
Human Factors
  • Uniformity of appearance
  • all menus follow a similar pattern
  • Rapid prototype of HCI obligatory

20
Rapid Prototyping as Specification Technique
  • No specification phase
  • Rapid prototype replaces specification document

21
Rapid Prototyping as Specification Technique
  • Specifications
  • use the prototype to determine what has to be
    done
  • add a list of additional features that the client
    wants
  • Advantages
  • Speed
  • No ambiguities, omissions, contradictions that
    arise from a specifications document

22
Rapid Prototyping as Specification Technique
  • Disadvantages
  • Specification document is contract prototype is
    not. Could have legal problems
  • Testing requires specifications
  • Maintenance requires specifications, otherwise
    will not know what the original software was to
    do.
  • Conclusion Do not use rapid prototype as
    specifications

23
Reusing the Rapid Prototype
  • Similar to Build-and-fix
  • Becomes expensive since it is expensive to change
    working software.
  • Built rapidly, so many possible faults.

24
Reusing the Rapid Prototype
  • No specifications, no design done.
  • Quality declines.
  • Maintenance difficult.
  • Real-time constraints.
  • prototype does not emphasize performance

25
Reusing the Rapid Prototype
  • Expensive option
  • Reuse rapid prototype
  • Cheap option
  • Discard rapid prototype
  • Should use different language for prototype and
    final product.
  • Guarantees prototype will be thrown away.

26
Reusing the Rapid Prototype
  • Can safely retain (parts of) rapid prototype if
  • Prearranged
  • Passes SQA inspections
  • This is not classical, ie, can no longer be
    rapid if code must meet such high standards.
  • Can safely reuse parts of the prototype if they
    were computer generated.
  • eg, use screen generators and report generators
    to generate the user interface.

27
Rapid Prototyping
  • Client perception
  • RP encourages client to request major changes
  • Client wants to use RP as final product
  • Client expects changes to final product to be as
    quick as changes to RP.

28
Rapid Prototyping
  • Management Implications
  • Immediate delivery
  • Instant maintenance
  • different than traditional Waterfall model
  • Waterfall modelget it right first time
  • Rapid prototypingmany changes, then discard
  • Increased interaction with clients
  • not true with other models they just use
    interviews

29
Case for Rapid Prototyping
  • Not proven beyond all doubt
  • Experiment of Boehm, Gray, and Seewaldt (1984)
  • Seven different versions of product compared
  • four specified, three prototyped
  • Prototyping, specifying yielded equivalent
    performance
  • Prototyped versions had 40 less code, 45 less
    effort
  • Prototyped versions were lower on functionality
    and robustness (speced versions added features
    because they didnt know how difficult
    implementation would be)
  • Prototyped versions were higher on ease of use
    and ease of learning
  • Specifying made integration easier

30
Case for Rapid Prototyping (contd)
  • Important facts (not often mentioned) about the
    experiment
  • Experiment on seven teams of graduate students
  • Three teams of size 2, and four teams of size 3
  • Ten week duration
  • No maintenance
  • Treat results as indications, not facts

31
Experiences with Rapid Prototyping
  • Analysis of 34 case studies Gordon and Bieman,
    1992
  • 29 successes, 2 failures, 3 neutral
  • (But few failures are published!)
  • All agreed
  • User participation was essential, user needs were
    met

32
Experiences with Rapid Prototyping
  • Not all issues were addressed in all case studies
  • (Only 16 mentioned ease of use, but all 16 were
    positive)
  • Choice of prototyping language was not important
  • 26 different languages used
  • Most popular lisp (4), Smalltalk (3)

33
Controversy
  • Discard or retain rapid prototype?
  • Diametrically different processes used
  • 18 recommended retention, 7 said discard
  • 6 out of 6 large projects recommended retention

34
Testing during the Requirements Phase
  • Aim establish clients real needs
  • Users must interact thoroughly with rapid
    prototype
  • Issues must reach client

35
CASE Tools for the Requirements Phase
  • Language for Rapid Prototyping
  • Interpreted languages environments (Lisp,
    Smalltalk)
  • Hypertext (HTML) for user interfaces
  • 4GL (Oracle, PowerBuilder, DB2)
  • Fewer statements needed to achieve functionality
  • Often interpreted
  • Often powerful CASE tools are available in 4GL

36
CASE Tools for the Requirements Phase
  • Danger of 4GL
  • Part of larger environment tempting to use these
    tools to build-and-fix the prototype
  • Cheap solution buying a separate RP tool is
    expensive

37
Metrics for the Requirements Phase
  • Quality, reliability?
  • Volatility, convergence how fast do the
    requirements change and converge.
  • Changes during subsequent phases
  • Number of times each feature is used
  • the more often a feature is used, the more
    important it may be to the user
  • less used features may be candidates for
    discarding.

38
Object-Oriented Requirements Phase
  • On the one hand
  • The aim is to find the clients needs
  • Objects dont enter into it theyre design
    techniques
  • On the other hand
  • Using an object-oriented language for the rapid
    prototype may help to identify classes

39
Air Gourmet Case Study Requirements Phase
  • See pages 308 through 311 of the Fifth Edition of
    Object-Oriented and Classical Software
    Engineering
  • Read this before the next class!

40
Air Gourmet Case Study Rapid Prototype
  • C and Java repid prototypes are available on the
    Web at www.mhhe.com/engcs/compsci/schach
  • For speed in implementation
  • Data are stored in fixed-size arrays
  • 10 passenger records are stored in an array
  • 20 flight records are stored in an array
  • in final version, must allow unlimited numbers
    in arrays

41
Air Gourmet Case Study Rapid Prototype
  • Only two reports are implemented (the other four
    are similar)
  • report on low-sodium meals
  • report on meals onboard the flight.
  • other 4 reports are similar to the two that are
    implemented.
  • other 4 reports are implemented as stubs. Just
    display a message when invoked.

42
Air Gourmet Case Study Rapid Prototype
  • Interface is menu driven
  • not as elegant as a graphical user interface
  • but is fast to create
  • GUI is often OS specific

43
Portion of Rapid Prototype
  • C
  • Java

44
Challenges of the Requirements Phase
  • Employees of the client organization feel
    threatened by computerization
  • Requirements team members must be able to
    negotiate with the client
  • The clients needs may have to be scaled down
  • Key employees of the client organization may not
    have the time for essential in-depth discussions
  • Flexibility and objectivity are essential
  • developer should not have any preconceived ideas
Write a Comment
User Comments (0)
About PowerShow.com