quick review understanding requirements software...

Agenda

• Quick Review

• Understanding requirements

• Software Process

1CSE 5324, Summer 2017, Ali Sharifara

Quick Review

• What is unique about software?

• What is software process?


The Software Process

CSE 5324, Summer 2017

Outline

• A Generic Process Model

• The Waterfall Model

• The Spiral Model

• The Unified Process Model

• Process Assessment and Improvement


A Generic Process Model

• A framework activity is

populated by a set of

actions

• Each action is defined

by a task set

– Tasks, work products,

quality measures, and

milestones


How to Define a Framework

Activity

• Depends on the nature of the project

• Consider the communication activity

– Example 1: For a small project, the only necessary

action can be a phone conversation

– Example 2: For a more complex project, the

actions may include inception, elicitation,

elaboration, negotiation, specification and

validation.


How to Identify a Task Set

• Also depends on the nature of the project

• Consider the elicitation or requirements gathering action


Example 1

• Make a list of stakeholders

• Invite all stakeholders to an

informal meeting

• Ask each stakeholder to make

a list

• Discuss requirements and

build a final list

• Prioritize requirements

• Note areas of uncertainty

Example 2

• Make a list of stakeholders

• Interview each stakeholder

• Build a preliminary list

• Schedule a series of facilitated

meetings

• Conduct meetings

• Produce informal user

scenarios as part of each

meeting

• …

The Waterfall Model


The different stages are performed in a linear fashion. (A sequential approach

to software development)

The Waterfall Model

• Advantages:

– The model is simple and easy to understand

– The model works well for small projects where requirements are very well

understood.

– It is easy to manage due to the rigidity of the model – each phase has

specific deliverables and a review process.

– Phases are processed and completed one at a time. Phases do not overlap.

• Disadvantages:

– Software delivered very late, and may delay discovery of serious errors.

– Difficult to make changes.

– Limited interaction with the user, only in the requirements stage and in the

deployment stage.

– Testing only performed at the end of the process.

– Failures/problems detected during testing can be very costly to fix.

– Emphasize completing a phase before going to the next one.

– High amounts of risk and uncertainty.


Why Not Waterfall?


This diagram is about features.

Almost 65% of the waterfall-

specified features were of little or

no value

A working model is not

available until late in the

project time space. Thus,

a major error may be

undetected until the very

late in the project, which

can be disastrous.

The V Model


This model is also known as Verification and Validation model

The V Model

• Testing is emphasized in this model.

• Test plan is developed during each phase prior to

implementation.

– Test plans should not be made only at the end of a project.

• Advantages:

– Higher chance of success over the waterfall model due to

the early development of test plans.

– Proactive defect tracking – that is defects are found at early

stage.

• Disadvantages:

– Very rigid and least flexible. (like the waterfall model)

– Fundamentally the same as the waterfall model.


The Spiral Model


Building progressively

more complete

versions.

Each cycle consists of four

phases: Planning, Risk

Analysis, Engineering and

Evaluation.

Each time when crossing

the horizontal line, the

customer is involved to

review the progress.

Each phase begins with

a design goal and ends

with the client reviewing

the progress.

The Spiral Model (2)

• Each phase is ended with a review by

concerned people

• Good for large and mission critical projects,

but risk analysis is critical and depends on

highly specific expertise

• Strong approval and documentation control.

• Additional Functionality can be added at a

later date.

• Software is produced early in the software life

cycle.


Risk and Risk Management plan

• Risks are situations or possible events that may cause a project

to fail to meet its goals.

• Risk management plan : Enumerates the risks and prioritizes

them in degree of importance, measured by a combination of

the impact and probability of each.

• For each risk, the plan also includes a mitigation strategy to deal

with the risk. For example, if the risk is that a particular technology

may not be ready, we could build an appropriate prototype

implementation in an early spiral cycle to evaluate the technology.

– Project cost overruns,

– Changed requirements,

– Technological advancement,

– Loss of key personnel,

– Competition from others

– Delay of hardware


The UP Model


The UP Phases

• Inception: Approximate vision, business case,

scope, vague estimates

• Elaboration: Refined vision, identification of all

the major requirements, resolution of high risks,

the core architecture (or baseline design), and

more realistic estimates

• Construction: Iterative implementation of the

remaining lower risk and easier elements

• Transition: beta tests, user documents, ready for

deployment (support, sales, etc)


The UP Phases (2)


The UP Phases (3)


The UP Model (2)

• Iterative and Evolutionary: Each phase is

divided into a series of time-boxed iterations.

• Use Case Driven: Each iteration takes a set

of use cases from requirements all the way

down.

• Architecture Centric: Architecture drives the

exploration of all aspects of the system

• Risk Focused: High risk tasks are addressed

early in the project lifecycle


Iterative and Evolutionary


UP Work Products


Feedback and Adaptation

• Feedback from early development to refine

requirements

• Feedback from tests and developers to refine

designs or models

• Feedback from early progress to refine

schedules and estimates

• Feedback from client and marketplace to re-

prioritize features


Feedback and Adaptation (2)


Elaboration Phase in Detail

• Use Case Analysis

– Find and understand 80% of architecturally

significant use cases and actors

– Prototype User Interfaces

– Prioritize Use Cases within the Use Case Model

– Detail the architecturally significant Use Cases

(write and review them)

• Prepare Domain Model of architecturally significant

classes, and identify their responsibilities and central

interfaces (View of Participating Classes)


Use Case Analysis

• What is a Use Case?

– A sequence of actions a system performs that

yields a valuable result for a particular actor.

• What is an Actor?

– Anything that needs to interact with the system. It

can be a person or another (external) system

• Use Cases describe scenarios that describe the

interaction between users of the system and the

system itself.

• Use Cases describe WHAT the system will do, but

never HOW it will be done.


Use Case Analysis cont.

• A use case is a flow of events in the system,

including interaction with actors

• It is initiated by an actor

• Each use case has a name

• Each use case has a termination condition

• Graphical Notation: An oval with the name of the use

case


ReportEmergency

Name of Use Case

Actors: Description of Actors involved in use case)

Entry condition: “This use case starts when…”

Flow of Events: Free form, informal natural language

Exit condition: “This use cases terminates when…”

Exceptions: Describe what happens if things go wrong

Special Requirements: NFR, Constraints

What’s in a Use Case?

• Define the start state and any preconditions that accompany it

• Define when the Use Case starts

• Define the order of activity in the Main Flow of Events

• Define any Alternative Flows of Events

• Define any Exceptional Flows of Events

• Define any Post Conditions and the end state

• Mention any design issues as an appendix

• Accompanying diagrams: State, Activity, Sequence Diagrams

• View of Participating Objects (relevant Analysis Model Classes)

• Logical View: A View of the Actors involved with this Use Case,

and any Use Cases used or extended by this Use Case


Use Cases Describe Function not Form

• Use Cases describe WHAT the system will do, but never HOW

it will be done.

• Use Cases are Analysis Products, not Design Products.


Use Cases Describe Function, not Form

• Use Cases describe WHAT the system should do,

but never HOW it will be done

• Use cases are Analysis products, not design

products


Example – Use case


Benefits of Use Cases

• Use cases are the primary vehicle for requirements

capture in UP

• Use cases are described using the language of the

customer

• Use cases provide an easily-understood

communication mechanism

• When requirements are traced, they make it difficult

for requirements to fall through the cracks

• Use cases provide a concise summary of what the

system should do at an abstract (low modification

cost) level.


Use Case Associations

• A use case model consists of use cases and use

case associations

– A use case association is a relationship between use cases

• Important types of use case associations: Include,

Extends, Generalization

– Include

• A use case uses another use case (“functional decomposition”)

– Extends

• A use case extends another use case

– Generalization

• An abstract use case has different specializations


Heuristics: How do I find use cases?

• Select a narrow vertical slice of the system

• Discuss it in detail with the user to understand the

user’s preferred style of interaction

• Define the scope of the system.

• Discuss the scope with the user

• Use illustrative prototypes as visual support

• Find out what the user does


Analysis Model

• In Analysis, we analyze and refine the requirements described

in the Use Cases in order to achieve a more precise view of the

requirements, without being overwhelmed with the details

• Again, the Analysis Model is still focusing on WHAT we’re going

to do, not HOW we’re going to do it (Design Model). But what

we’re going to do is drawn from the point of view of the

developer, not from the point of view of the customer

• Whereas Use Cases are described in the language of the

customer, the Analysis Model is described in the language of

the developer:

– Boundary Classes

– Entity Classes

– Control Classes


Process Assessment and

Improvement

• To ensure that a software process meets a

set of basic process criteria

– SCAMPI (Standard CMMI Assessment Method for

Process Improvement)

– CBA IPI (CMM-Based Appraisal for Internal

Process Improvement)

– SPICE (ISO/IEC 15504, Software Process

Improvement and Capability Determination)

– ISO 9001:2000 for Software (A generic standard

for quality improvement)


CMMI

• Level 1, Initial: Process unpredictable, poorly

controlled, and reactive

• Level 2, Managed: Process characterized for

projects and is often reactive

• Level 3, Defined: Process characterized for

the organization and is proactive

• Level 4, Quantitatively Managed: Process

measured and controlled

• Level 5, Optimizing: Focus on continuous

process improvement


Summary

• In the waterfall model the different stages are performed in a

linear fashion (sequential)

– Suitable for small projects

• The spiral model is similar to the incremental model, with more

emphasis placed on risk analysis.

• V-model is also known as Verification and Validation model and

testing is emphasized in this model.

• UP is an Iterative and evolutionary model.

– Each phase is divided into a series of time-boxed iterations.

• Use case is a sequence of actions a system performs that yields

a valuable result for a particular actor.

• Actor is Anything that needs to interact with the system. It can

be a person or another (external) system.


quick review understanding requirements software...

Documents