cs562 Notes
Jan. 17, 2014

In the previous lecture, we reviewed the contents of the group project and the overview of  the course.

Review of items from last semester.
	Refer to the notes at http://catpages.nwmissouri.edu/m/monismi/cs561

When designing your project recall that you need to have proper background and an effective design.
	Domain analysis - gaining background information on the project
	Requirements gathering - understanding what needs to be done and how to do it.
	
	Design - UML, ER Diagrams, Use Cases, etc.
		Exploratory Domain Model vs. System Domain Model vs. System Model

	Basic Design Principles
		Cohesion - stickiness or things that go together.

		Coupling - interdependencies between modules.

		Increase cohesion and decrease coupling where possible.
	
		Refer to last semester’s notes on coupling and cohesion when necessary.

		Utilize design patterns where possible

	Further Design, Development, Testing, and Maintenance

		To be covered in future lectures

	Team work - to be covered today

		Chapter 4 of the textbook covers many process methodologies.

		Chapter 5 covers those that were developed more recently including Agile

Agile Processes

	Produce software in short iterations and allow for design changes

	Not necessarily new or revolutionary

	What is agile?  A mindset.

	Agile: adjective. able to move quickly and easily

	We will review the Agile Manifesto - http://agilemanifesto.org/

What are Agile Processes - Notes from Chapter 5
	Focus on short iterations
	Deliver software to the customer frequently
	Design the project incrementally
	Continuously involve the users in the design and development process
	Reduce documentation
	Use time effectively and allow for informal communication
	Includes refactoring to allow for significant modification of project over time

Agile Iterations

	Often last less than a month (1 to 3 weeks)
	Include short term planning
	Time estimation for features - planningpoker.com
	Client decisions on features
	Include user stories, development, and unit tests

Levels of Agile process
	Release - features to implement
	Iteration - short term goals
	Daily - immediate work toward iteration

User stories define features
	Shorter than use cases
	Several sentences (2 or 3)
	Gives developers an idea of how much time the task will take
	May require additional information before implementation
	Assist with user acceptance testing by including acceptance test as part of
	the user story

Unit tests should be created before modules are developed
	Ensure refactoring does not break a project
	Understand problem before implementing it


Agile Processes
	Extreme Programming
	SCRUM
	Crystal Family
	Others

Extreme Programming
	Used by Kent Beck from Chrysler Corp.
	Use small teams
	Little documentation - code and unit tests

Core Values
	Frequent communication
	Simple code and design
	Complete feedback - coder, customer, user, management
	Courage to make hard decisions

Principles
	Rapid feedback
	Simplicity
	Incremental Change
	Embracing Change
	Quality

	Continual Learning
	Low up front investment
	Experimentation
	Communication and Measurement (Honest)
	Many others

Key Practices
	Planning
	Short release times
	Use of metaphors rather than formal architectures
	Simple design
	Test-driven development
	Refactoring - restructuring the system without changing its behavior
	Pair programming
	Collective Ownership
	Continuous Integration
	Sustainable Pace
	On-Site Customer
	Coding Standards

SCRUM
	Introduced by Takeuchi and Nonaka in 1986
	Adopted from Rugby
	Used by Ken Schwaber and Mike Beedle in the book Agile SW Development with Scrum

	Iterative method
	Based on short iterations called sprints
	Sprints are the basic unit of development
		-one month or less
		-time-boxed
		-scope is adjustable if necessary
		-complete a distributable product by the end of the sprint

	Roles
		Product owner - voice of customer, ensures product is valuable to the business
		development team - 3 to 10 developers
		Scrum Master - keeps team on track, ensures Scrum is followed, not a project leader
		Stakeholders
		Managers

	Pillar Concepts
		Transparency
		Inspection
		Adaptation (when necessary)

	Events
		Sprint planning meeting - what will be done in the sprint
		Daily scrum - 15 min or less to ensure everyone is on track
		Sprint review - done at end of sprint to update backlog, to debrief, and
		to decide what to do next
		Sprint retrospective - done after sprint review to discuss results, learn
		from them and use as future lessons
	
	Scrum Artifacts
		Product backlog - list of all remaining requirements/user stories
		Sprint backlog - ordered list of all tasks for the current sprint
			Tasks are 4-16 hours long and developers choose their own tasks

		Increment - current project, sum of all requirements completed in this and
		previous sprints.  May not be complete, but should be distributable
		Burn down chart - publicly displayed chart showing the remaining log in
		the current sprint backlog

Crystal Family is to be discussed later