1. School of Business Administration
Software Engineering
Fall Term 2015
Marymount University
School of Business Administration
Professor Suydam
Week 4

2. Agenda for Week 4 Mini-Project 1 Class Discussion
Twelve Innovation Lessons for 2014
Chap 5 Software Process Models
UML Text Chap 9 & Introduction to MS Visio
Mini-Project 1 Discussions

3. Mini-Project 1 -- Class Discussion

4. Twelve Innovation Lessons for 2014
Innovative Companies

5. Chapter 5 - Problems with “Traditional” Processes
Focused on and oriented toward “large projects” and lengthy development time (years)--- started SWE
Inability to cope with changes in requirements and technology fast enough --- “formal” change management
Assumes requirements are completely understood at beginning of project --- stable requirements
Starting to rely on “non-sustainable” heroic and lengthy development effort by the developers --- hard to maintain “constantly high” productivity
Complex set of activities --- needed process experts
Waste or duplication of effort, especially in documentation --- formal documentation needed for long and large project communications

6. More Recent Processes: Agile Methodologies
Family of software development methodologies:
“Short” releases and multiple iterations
Incremental design/development
User involvement (especially for in-house)
Minimal documentation
Informal communications
Assumes changes

7. Some Agile Methodologies
Extreme Programming (XP) --- the first by Beck (1990’s)
Crystal Clear/Orange – by Alister Cockburn
SCRUM ---- currently popular (not really part of Agile --- partially agile)
RUP (Rational Unified Process)
Microsoft Solutions Framework (tool/process)

8. Extreme Programming (XP)
XP Core Values
Communication (between team and with customers)
Simplicity (in design and code)
Feedback (at many levels)
Courage (to make and implement difficult decision)
XP Fundamental Principles
Rapid feedback
Simplicity
Incremental change
Embrace change
Quality work
Other Principles
Ongoing learning
Small initial investment
Playing to win
Concrete experiments
Open, honest communications
Working with people’s instincts
Accepting responsibility
Local adaptation
Traveling light
Honest measurement
Directly from “core” values

9. XP’s 12 Key Practices
Based on the concept of quick and constant “feedback mechanism” involving:
Planning Game (Small Units of Requirements)
Onsite Customer (Immediate and better feedback)
Metaphor (Use one set of metaphor for design/architecture)
Simple Design (Just enough to cover what’s needed)
Coding Standard (Facilitates better communication)
Collective Code Ownership (Peer pressure to improve code)
Pair Programming (Feedback and shared improvements)
Refactoring (Continuous examination for duplicative design/code)
Continuous Functional and Unit Testing (100% completion)
Small/short releases
Continuous Integration (integrating of small releases)
40 hour work (high morale and energy level)
some
recognition of
“human”
aspects

10. Extreme Programming “Process”
Onsite Customers
Coding standards
Simple Design
Planning
Game
Pair Programming
Functional &Unit Test
Small/short
Release
System Metaphors
Continuous Integration
Refactoring
Collective Code
Ownership
Larger
Release
Adhere to 40 hour work week as much as possible ! -- sustainable pace

11. Crystal Family of Methodologies
Cockburn classified projects via:
Size (by number of developers involved)
Criticality (by losses a malfunction or defect will cause - “quality”)
Priority (time pressure on the project)
Alistair Cockburn introduced a family of 3 methodologies
Crystal Clear for “non-critical” projects (6-8 people)
Crystal Orange for “critical” projects (up to 40 people)
Crystal Orange Web – for web development

12. Scrum Development Process (Currently Popular)
First introduced by Takeuchi and Nonaka (Japan) in 1986 modeled after the way rugby game is played.
Ken Schwaber and Mike Beedle published a book, “Agile Software Development with Scrum,” in 2001.
It is an incremental and iterative development approach:
Develops small “sprints,” or increments (of features) in a short cycle of about 2-3 weeks.
There are 3 main roles
Product Owner who talks to & decide with users about the content of each sprint
Scrum Master who runs the sprints
Scrum Team of about 7-8 members who develop the sprint

13. UML VTC Chap

14. Text Introduction to Use Cases Chap 9

15. Introduction to UML in MS Visio

16. Use Cases and Actors
A use case is a type of complete interaction between and product and its environment.
An actor is a type of agent that interacts with a product.
The collection of use cases characterizes all externally observable behavior.
A use case is an entire, coherent interaction.
Actors are roles not individuals.
The product is never an actor.

17. Use Case Diagrams Static model Catalog of all use cases UML diagram
A use case diagram represents a product’s use cases and the actors involved in each use case.
Static model
Catalog of all use cases
UML diagram

18. Use Case Diagram Symbols

19. Use Case Diagram Example
Use Case Diagram for an Automated Carwash

20. A Scenario Example Instance of a use case
A scenario is an interaction between a product and particular individuals.
Instance of a use case
Help envision how a product can be used
Abstracted into use cases
Buying a Car Wash Example
“Michael drives to the kiosk outside the carwash and attempts to insert five dollars. The kiosk accepts the money and displays the message “You have paid enough for a complete wash. Insert another dollar for a deluxe wash.” Michael presses the button for an express wash. The kiosk refunds one dollar. The carwash queries its stall sensors. The stall sensors report that no car is detected, so the kiosk displays the message “Please drive forward into the wash stall.”

21. Formation Rules Every use case diagram must have:
At least one use case
At least one actor
At least one actor associated with each use case
At least one use case associated with each actor
No association line between actors
No association line between use cases
Name every actor and use case
Not label any association line

22. Use Case Diagram Heuristics
Never make the product an actor.
Name actors with noun phrases.
Name use cases with verb phrases.
Achieve a stakeholder’s goal in a use case.
Make use cases that can be finished in a single session.
Make use cases of uniform size and complexity.
Draw use case diagrams on one page.
Organize use cases by actor, problem domain categories, or solution categories.