Answer & Explanation:Please make sure that you use full sentences in your responses1. What was the original purpose of software engineering process models and have they been successful?2. Which process model would you use when a problem is well defined and the software needs to be of high quality and is not deadline drive? Why?3. Explain the main differences between the Waterfall model and the Incremental model.4. Explain the rote of a prototype in any process model.5. Explain why it may not be advisable to extend a prototype into the production system.6. What process model would you recommended when you management demands fixed-budget development? Why?7. If you were putting a system development project out to bid, what would be a reasonable CMMI level to specify as a minimum requirement? Why?8. Describe the four phases of the spiral model.9. Explain how the phases of the RUP model relate to the generic process activities of software engineering.10. Explain Deming’s approach to process improvement.11. In your own words, describe the difference between a use case diagram and a use case narrative.12. Give three examples of actors for a hotel reservation system to illustrate the different roles that an actor (human or otherwise) can take.13. Describe the pre-conditions and post-conditions that you might include in a use case narrative for a guest at a hotel automatically checking out when they leave the hotel.14. Discuss three reasons why collecting and understanding requirements might be difficult for the IT team developing the hotel reservation system.15. Describe two of the outputs from the requirements elicitation phase of requirements engineering.16. Provide one example of a functional and one non-functional requirement for the hotel reservation system.17. Create a user story for a hotel clerk who is checking in a new guest who has a reservation in the system (front of the card only)18. Create a user story for the hotel manager who is generating a report at the end of the day to see how full the hotel is at that time (front of the card only)19. User stories are part of the agile development process, discuss why they work for this style of development20. For the user story where a hotel clerk is checking in a new guest who says they have a reservation, describe the success and failure conditions that would ne placed on the back of the card.
it210unit04a.ppt
it210unit02b.ppt
it210_unit4_example.docx
unit03a.ppt
process_models_se_encyc.pdf
Unformatted Attachment Preview
IT210
Software Engineering
Unit 4A – Use Cases
Fall 2016
5/7/2019
1
Understanding Requirements
• One of the most difficult tasks is to collect and
document requirements
• Customer does not always know or can articulate
what is required
• Users may be unduly influenced with what they
have now
• May be conflicts between the varios stakeholders
• Many developers want to jump in before they
have a clear understanding of all the
requirements
5/7/2019
2
Requirements Engineering
• Broad spectrum of tasks and techniques that
lead to an understanding of requirements
• Major software engineering activity that
begins during the communication activity and
continues into the modeling activity
• Adapted to the needs of the process, the
project, the product, and the people
• Builds a bridge to design and construction
• Encompasses seven distinct tasks
5/7/2019
3
Requirements Engineering Process
• Inception—ask a set of questions that establish …
–
–
–
–
Basic understanding of the problem
The people who want a solution
The nature of the solution that is desired, and
The effectiveness of preliminary communication and
collaboration between the customer and the developer
• Elicitation—elicit requirements from all stakeholders
• Elaboration—create an analysis model that identifies
data, function and behavioral requirements
• Negotiation—agree on a deliverable system that is
realistic for developers and customers
4
Requirements Engineering Process
• Specification—can be any one of the following:
–
–
–
–
–
A written document
A set of models
A formal mathematical model
A collection of user scenarios (use-cases)
A prototype
• Validation—a review mechanism that looks for
–
–
–
–
–
Errors in content or interpretation
Areas where clarification may be required
Missing information
Inconsistencies
Conflicting or unrealistic (unachievable) requirements
• Requirements management
5
Inception
• Identify stakeholders
– “who else do you think I should talk to?”
• Recognize multiple points of view
• Work toward collaboration
• The first questions
– Who is behind the request for this work?
– Who will use the solution?
– What will be the economic benefit of a
successful solution?
– Is there another source for the solution
that you need?
6
Example: Inception of Medical
Office Scheduling System
• The doctor wants to see more patients and
wants a good scheduling system to do that
• Answer the first questions
– Who is behind the request for this work?
– Who will use the solution?
– What will be the economic benefit of a successful
solution?
– Is there another source for the solution that you
need?
• Lets discuss what we know
5/7/2019
7
Eliciting Requirements
• Meetings are conducted and attended by both
software engineers and customers
• Rules for preparation and participation are established
• An agenda is suggested
• A “facilitator” (can be a customer, a developer, or an
outsider) controls the meeting
• A “definition mechanism” (can be work sheets, flip
charts, or wall stickers or an electronic bulletin board,
chat room or virtual forum) is used
8
Goals of Eliciting Requirements
• To identify the problem and get a common
understanding about the scope of the project
• Propose elements of the solution to include
an understanding of the technology
environment
• Negotiate different approaches within the
budgetary constraints
• Specify a preliminary set of solution
requirements
5/7/2019
9
Use Case Diagrams
• A use case is a set of scenarios that describing
an interaction between a user and a system
– What a system does…rather than how a
system does
• A use case diagram displays the relationship
among the users and the system and use cases
• The two main components of a use case
diagram are use cases and actors
Use-Case Scenarios
• Each scenario is described from the point-of-view of an
“actor”—a person/device that interacts in some way
• Each scenario answers the following questions:
– Who is the primary actor, the secondary actor (s)?
– What are the actor’s goals?
– What preconditions should exist before the story begins?
– What main tasks or functions are performed by the actor?
– What extensions might be considered as the story evolves?
– What variations in the actor’s interaction are possible?
– What information will the actor acquire, produce, or change?
– How will the actor changes in the external environment?
– What information does the actor desire from the system?
– Does the actor wish to be told about unexpected changes?
11
Use-Case Diagram
Arms/ disarms
syst em
Accesses syst em
via Int ernet
homeow ner
Responds t o
alarm event
Encount ers an
error condit ion
syst em
administ rat or
Reconf igures sensors
and relat ed
syst em f eat ures
12
sensors
Actor and Use Cases
• An actor represents a user or another system that will interact
with the system you are modeling
• A use case is an external view of the system that represents
some action the user might perform in order to complete a
task
When to Use: Use Case Diagrams
• Use cases are used in almost every development
methodology except Agile
• They are helpful in exposing requirements and planning the
project
• During the initial stage of a project most use cases should be
defined, but as the project continues more might become
visible
• Use cases are a relatively easy UML diagram to draw, but
following is a very simplified example.
• The example is only meant as an introduction to the UML and
use cases
Example
• Start by listing a sequence of steps a user might take in
order to complete an action. For example a user placing
an order with a sales company might follow these steps.
1.
2.
3.
4.
5.
Browse catalog and select item
Call sales person
Supply shipping information
Supply payment information
Receive conformation number by email
Developing a More Complex Use
Case Diagram
• Use case diagrams are meant to be a top-down, horizontal
description of functionality
– if functionality or behavior is added or deleted over the life of the
project, the scope of the change you need to make is proportional to
both the scope of the change in the system itself, and the maturity of
the model
– This is useful because it means that when the model is very young
(only high-level diagrams drawn) making sweeping changes to the
system does not involve throwing very much work away
How is a UCD different from a
traditional flow chart?
• A flow chart does not correctly describe the system until you
have finished drawing it, and even then small changes in the
system will result in significant reworking of your flow charts
– Complex logic: sometimes, the program logic is quite complicated. In
that case, flowchart becomes complex and clumsy
– Alterations and Modifications: If alterations are required the flowchart
may require re-drawing completely
– Reproduction: As the flowchart symbols cannot be typed,
reproduction of flowchart becomes a problem
– The essentials of what is done can easily be lost in the technical details
of how it is done
Convert to Use Case
• Let us look at how we can present the same
information in a use case
• Who are the actors
– Primary
– Secondary
• What functions are they doing?
• Who does what function to what?
5/7/2019
22
Activity 4A: A Medical Office
Scheduling System
• The receptionist asks the patient for their last name and date of
birth and sees if they are a patient and if they have any account
balance before making the appointment
• If a new patient, the receptionist asks the patient for additional
information such as their full name and address and advises them
to come in 30 minutes before the appointment to fill out the
necessary forms
• The receptionist asks the patient if they have any time constraints
(days and times) before looking up the schedule to find an
appointment
• The receptionist confirms that the appointment time is acceptable
to the customer before making the appointment
• If the patient agrees the receptionist records the patient’s name
and date of borth in the scheduling system
• Develop a use case diagram for this scenario
IT210
Software Engineering
Unit 2B
Fall 2016
5/7/2019
1
Topics
• Review of Software Process Models
–
–
–
–
Waterfall Model
Incremental Model
Spiral Model
Rational Unified Process
• Entry and Exit criteria
5/7/2019
2
Conept of a Process Model
It is a description of
i) what tasks need to be performed in
ii) what sequence under
iii) what conditions by
iv) whom to
achieve the “desired results.”
The Standard Software Development Process
Problem
Statement
Coding
Compiling
problem
Unit
Testing
Release
problem
Debugging
1. Most people performs and follow this simple process, but unfortunately
some skip or minimize unit testing or debugging.
2. Also, some proceeds without thoroughly considering & understanding the
“problem statement” —- which is the requirement
With More People and More Tasks
• We now need to “define”:
– Set of tasks that need to be performed throughout
the project
– Sequence of flow of the tasks to ensure efficiency
– Input and the output from these tasks
– Pre-condition and post-conditions for each task,
sometimes called entry and exit criteria
– People and skills needed to perform the tasks
• Numbers
• Job Titles
Waterfall Model
• Sometimes referred as the classic life cycle
• Used when the requirements for a problem
are well understood
• Work flows from communication through
deployment in a reasonably linear fashion
• Often used when a well-defined enhancement
to an existing system
– Change mandated by government regulation
change
• Requirements must be stable
5/7/2019
6
1. Requirements must be specified in the
first step.
2. Four main tasks must be completed in
sequence: requirements, design, code,
and test, followed by packaging.
3. Output of one stage feeds into the next
stage in sequence, and thus easily
tracked (“controlled”) by management
Requirements
Design
Code
Test
Waterfall Model
Integrate and
Package
Pros and Cons?
V-Model
• Variation in the representation of the
Waterfall Method
• Includes the relationship of quality assurance
actions to the various processes
• Once coding is complete, begin the testing
cycle
5/7/2019
8
The V-Model
9
Incremental Process Models
• Software requirements reasonably well
defined BUT the overall scope of the
development effort precludes a linear
sequential process
• May be a compelling reason to get some
software functionally to the customer
• Expand and refine software functionality in
later releases of the software
• Applies linear sequence in a staggered fashion
over the timeline of the project
5/7/2019
10
1. Each “major requirement/item”
is further developed separately through
the same sequence of : requirement,
design, code, and unit test.
2. As the developed pieces are completed,
they are continuously merged and
integrated into a common bucket for
integrated system test
Req. Analysis and Architecture
Req. 1
Req.2
Des.
…
Des.
Req. n
….
Des.
code
code
……
code
Test
Test
……
Test
Integration Bucket
Pros and Cons
System
Test
The Spiral Model
• Couples the interactive nature of prototyping
with the controlled and systematic aspects of
the waterfall model
• Potential for rapid development of
increasingly more complete versions of the
software
• Each iteration may be release or a prototype
• Risk is considered as each iteration is made
• Widely used for large-scale systems
• Anchor point milestones
– Combination of products attained along the path 12
5/7/2019
Determine Objectives,
Alternatives, Constraints
Evaluate Alternatives,
Identify, Resolve Risks
risk
analysis
design
proto model
type
“Review”
req. plan
dev plan
test plan
Plan Next Phase
req.
Spec. design
design
validation
sys.
test
code
unit
test
Develop, Verify
Next-level Product
Pros and Cons?
Spiral Model
Rational Unified Process (RUP)
• Developed by Rational Software Corporation,
later acquired by IBM
• Based on Unified Modeling Language (UML)
paradigms
• Incorporated earlier experiences from
incremental and spiral processes
• Three major concepts:
– Use case and requirements driven
– Architecture centric
– Iterative and incremental
5/7/2019
14
Phases of Project
Activities
Inception
Elaboration
Construction Transition
Requirements
Design
Implement
Test
Integrate
Rational Unified Process (RUP)
Pros and Cons?
Every software development
activity is “addressed” in the 4
phases of inception, elaboration,
construction, and transition
Evolutional Process Models
• Software evolves over a period of time
– Requirements often change as development proceeds
– Technology changes in the development timeframe
• A limited version may be necessary to meet
competitive business pressures
• Core set of features is well understood but the
details of the enhancements have yet to be
defined
• Need iterative models that develop increasingly
more complex software
5/7/2019
16
Prototyping
Q u i ck p l an
Quick
plan
Com m unicat ion
communication
Mo d e l i n g
Qu i ck d e si g n
Modeling
Quick design
Deployment
Deployment
De live r y
delivery
&
& Fe e dback
Construction
of Const
prototype
r uct ion
Construction
of
of
prototype
pr ot
ot ype
feedback
Pros and Cons?
17
Entry and Exit Criteria
Entry
Criteria
Yes
Process
Activity
Exit
Criteria
Yes
Met?
Met?
No
No
For process models to be more than just a “guideline,” it must include a
list of conditions or requirements that define the:
– entry criteria prior to performing
an activity in a process.
– exit criteria before an activity in the
process is deemed completed
Activity 2B
• In your group, give 2 entry and 2 exit criteria for the
assigned step in the process:
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
Waterfall – Design
Waterfall – Code
Waterfall – Test
Incremental –Design
Incremental – Code
Incremental – Test
Spiral – Evaluate alternatives etc.
Spiral – Develop, verify next level product
Spiral – Plan next phase
RUP – Elaboration
RUP – Construction
RUP – Transition
Present to class and upload to Activity 2B
19
IT210
Software Engineering
Unit 3A
More on Processes
Fall 2016
5/7/2019
1
Topics
•
•
•
•
•
Review of Quiz 1
Process Improvement
CMMI
ISO 9000 series
Other Process Improvement Techniques
5/7/2019
2
Review of Quiz 1
• Thanks to those of you who submitted on
time
– Questions on Timing
– Questions on questions/expectations
• 5 of you submitted late
– Penalty?
• 2 of you have not submitted?
– Zero
• Will Grade tomorrow
5/7/2019
3
Purpose of Quiz
• Content
– Answer the question
• Writing
– Good sentence structures
• Response time
– Not necessarily have time to look everything up
• Critical thinking
– “Intellectually disciplined process of actively and
skillfully conceptualizing, applying, analyzing,
synthesizing, and/or evaluating information”
5/7/2019
4
The Process Management Premise
• The quality of a system is influenced by:
• Quality of the process used to acquire, develop, and maintain it
• Analysis and forethought that goes into an architecture that
supports business goals and requirements
• Training provided to teams involved in the project
• Using proven methods for process and product quality,
software success is predictable and achievable, and failure
is avoidable
• Once coding starts, teams trained in mature software
engineering processes can remove defects early, when
defect removal is 10 to 100 times less costly than it is
during testing
• This dramatically reduces testing costs and only marginally
increases costs upstream
Common Misconceptions
•I do not need defined processes I have:
• Really good people
• Advanced technology
• An experienced manager
•Defined Processes:
•
•
•
•
•
•
Interfere with creativity
Equals bureaucracy + regimentation
Is not needed when building prototypes
Is only useful on large projects
Hinders agility in fast moving projects
Costs too much
Symptoms of Process Failure
• Commitments consistently missed
• Late deliveries
• Last minute crunches
• Spiraling costs
• No management visibility into progress
• Managers are always being surprised
• Quality Problems
• Too much rework
• Functions do not work correctly
• Customer complain after delivery
• Poor Moral
• People frustrated
• Is anyone in charge?
Why Structured Processes
•Estimating (History)
–
–
–
–
Scope
Cost
Time
Tools
•Deliver the Product to Estimate (Visibility)
– Time
– Cost
– Quality
•Handling/Controlling Changes
– Planned
– Unplanned
– Scope Creep
Why We Need Standard Processes
• Organizations and governments worldwide
will spend about $1 trillion this year on IT
projects
• Recent data suggested only about 35 percent
of those projects are likely to be completed on
time and on budget with all their originally
specified features and functions
• Many projects, perhaps 20 percent, will be
abandoned, often after multimillion-dollar
investments—and the biggest projects will fail
most often
Examples of Software Failures
• One well-documented $170 million software failure
was blamed on:
• Lack of defined requirements in the original contract
• A lack of software engineering, program, and contract
management skills
• Underestimates of the complexity of interfacing the new
system with legacy systems
• Addressing security needs, and establishing an enterprise
architecture.
• Other software-development failures have brought
down entire companies, such as the $5 billion drugdistribution firm in Texas that declared bankruptcy as
a result of a poorly implemented ERP system
5/7/2019
10
Assessment of Software Organizations
• Software Development and Software Support may be done with
very little process or with very sophisticated, well defined, well
organized and well executed processes.
• How mature is a software engineering organization and does it
need to improve?
• ISO (ISO 9000 series) and SEI (Software Engineering Institute at
Carnegie Mellon) are two leading organizations that help in the
process assessment
Matured Process
No Process
Where is a company in
this wide spectrum??
What are Standards?
• Standards are documented agreements containing
technical specifications or other precise criteria to
be used consistently as rules, guidelines, or
definitions of characteristics, to ensure that
materials, products, processes and services are fit
for their purpose
• For example, the format of the credit cards, phone
cards, and “smart” cards that have become
commonplace is derived from an ISO International
Standard
• Adhering to the standard, which defines such
features as an optimal thickness (0,76 mm),
means that the cards can be used worldwide.
SEI’s Original CMM – Early 1990s
• Software Engineering Institute (SEI) proposed a Capability Maturity Model
(CMM) to help software organizations assess their maturity and provide
guidance in software development.
– Initial : there is no process and any success is by luck or with a special person.
– Repeatable: has mastered 6 processes and can repeat its success with these 6
processes: 1) requirements management, 2)project tracking, 3)quality assurance,
4)project planning, 5)subcontract management, and 6)configuration management
– Defined: has mastered 7 more processes and is competent at software
construction: 1) organization process, 2) training program, 3) product engineering,
4) peer review, 5) organization process definition, 6) integrated soft. management,
and 7) inter-group coordination
– Managed …
Purchase answer to see full
attachment
Order a plagiarism free paper now. We do not use AI. Use the code SAVE15 to get a 15% Discount
Looking for help with your ASSIGNMENT? Our paper writing service can help you achieve higher grades and meet your deadlines.
Why order from us
We offer plagiarism-free content
We don’t use AI
Confidentiality is guaranteed
We guarantee A+ quality
We offer unlimited revisions