1. Software Development Methodologies
Asst. Prof. Dr. Warodom Werapun
(From Dr. Somchai LIMSIRORATANA)

2. Class Timetable & Scoring
Sec 01: Fri: Room: 6702
Scoring
Assignment & Homework 25%
Class %
Midterm examination %
Final examination %

3. CH01 - Software Development Methodology
Requirement Analysis
CH01 - Software Development Methodology

4. Software Requirements Analysis Phases
Problem recognition
Evaluation and synthesis
focus is on what not how
Modeling
Specification
Review

5. Requirements Requirement
features of system or system function used to fulfill system purpose.
Focus on customer’s needs and problem, not on solutions:
Requirements definition document
(written for customer).
Requirements specification document
(written for programmer; technical staff).

6. Types of Requirements - 1
Functional requirements:
input/output
processing.
error handling.
Non-functional requirements:
Physical environment (equipment locations, multiple sites, etc.).
Interfaces (data medium etc.).
User & human factors (who are the users, their skill level etc.).

7. Types of Requirements - 2
Non-functional requirements (continued):
Performance (how well is system functioning).
Documentation.
Data (qualitative stuff).
Resources (finding, physical space).
Security (backup, firewall).
Quality assurance (max. down time, MTBF, etc.).

8. Use Cases
Scenarios that describe how the product will be used in specific situations.
Written narratives that describe the role of an actor (user or device) as it interacts with the system.
Use-cases designed from the actor's point of view.
Not all actors can be identified during the first iteration of requirements elicitation, but it is important to identify the primary actors before developing the use-cases.

9. Adapted from Larman “Applying UML and Patterns”
Sample Use Cases
POST: Point of Sale Terminal
Use Case
POST
System Boundary
Buy Item
Log In
Cashier
Customer
Refund a Purchased Item
Adapted from Larman “Applying UML and Patterns”

10. Planning Review
Agile

11. Agile Manifesto http://www.agilemanifesto.org A Statement of Values
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

12. Scrum in 100 words
Scrum is an agile process that allows us to focus on delivering the highest business value in the shortest time.
It allows us to rapidly and repeatedly inspect actual working software (every two weeks to one month).
The business sets the priorities. Our teams self-manage to determine the best way to deliver the highest priority features.
Every two weeks to a month anyone can see real working software and decide to release it as is or continue to enhance for another iteration.

13. How Scrum Works?

14. Product Owner Define the features of the product
Decide on release date and content
Be responsible for the profitability of the product (ROI)
Prioritize features according to market value
Adjust features and priority every iteration, as needed 
Accept or reject work results.

15. The Scrum Master Represents management to the project
Responsible for enacting Scrum values and practices
Removes impediments
Ensure that the team is fully functional and productive
Enable close cooperation across all roles and functions
Shield the team from external interferences

16. Scrum Team Typically 5-10 people Cross-functional
QA, Programmers, UI Designers, etc.
Members should be full-time
May be exceptions (e.g., System Admin, etc.)
Teams are self-organizing
What to do if a team self-organizes someone off the team??
Ideally, no titles but rarely a possibility
Membership can change only between sprints

17. Parts of Sprint Planning Meeting
1st Part:
Creating Product Backlog
Determining the Sprint Goal.
Participants: Product Owner, Scrum Master, Scrum Team
2nd Part:
Participants: Scrum Master, Scrum Team
Creating Sprint Backlog

18. Daily Scrum
Parameters
Daily
15-minutes
Stand-up
Not for problem solving
Three questions:
What did you do yesterday
What will you do today?
What obstacles are in your way?
Is a meeting in which team members make commitments to each other and to the Scrum Master
Is a good way for a Scrum Master to track the progress of the Team

19. Sprint Review Meeting
Team presents what it accomplished during the sprint
Typically takes the form of a demo of new features or underlying architecture
Informal
2-hour prep time rule
Participants
Customers
Management
Product Owner
Other engineers

20. Sprint Retrospective Meeting
Scrum Team only
Feedback meeting
Three questions (Good, Bad, Try …)
Start
Stop
Continue
Don’t skip for the first 5-6 sprints!!!

21. Sample Product Backlog

22. Sample Sprint Backlog

23. Pros/Cons Advantages Drawbacks
Completely developed and tested features in short iterations
Simplicity of the process
Clearly defined rules
Increasing productivity
Self-organizing
each team member carries a lot of responsibility
Improved communication
Combination with Extreme Programming
Drawbacks
“Undisciplined hacking” (no written documentation)
Violation of responsibility
Current mainly carried by the inventors

24. Development Environments
U03 - Software Development Methodology

25. Topics Tools Version Control (Git)
Text Editor or IDE (Integrated Development Environments)
Software Development Kits (Build & Run)
Library/Packages Manger
Tracing and/or Debugging
Version Control (Git)

26. Tools Corresponding to course's requirements
Standalone Application (Java)
IDE = Eclipse
Web Application (Node.js, Angular.js and MongoDB)
Editor = Sublime
Web Server = Node.js
JavaScript Library Manager = Bower
Test Environment = Chrome
Tracing & Debugging = Chrome Inspector

27. Eclipse
Maven is a build automation tool used primarily for Java projects
Describes how software is built and its dependencies

28. Maven Dependencies
Manually adding library to your project is painful, especially when your library has dependencies.
Just focus on what you want
<dependency>
<groupId>joda-time</groupId>
<artifactId>joda-time</artifactId>
<version>2.4</version>
</dependency>

29. Version Control
Version control (or revision control, or source control) is all about managing multiple versions of documents, programs, web sites, etc.
Almost all “real” projects use some kind of version control
Essential for team projects, but also very useful for individual projects
Some well-known version control systems are CVS, Subversion, Mercurial, and Git
CVS and Subversion use a “central” repository; users “check out” files, work on them, and “check them in”
Mercurial and Git treat all repositories as equal
Distributed systems like Mercurial and Git are newer and are gradually replacing centralized systems like CVS and Subversion

30. Centralized VC vs. Distributed VC
Visual Studio Live! Las Vegas 2011MGB 2003
Centralized VC vs. Distributed VC
Central Server
Remote Server
This is over simplifying the story, but the basics are that centralized version control system define a central authority.
I am not saying one system is better that the other, it is just that each model that its benefits.
In the distributed model by definition everything is expected to be off line. To have a system that expects everything to be offline, you have to build in several local capabilities that are not required in a centralized model.
Such as local branching. And to make branching fast and lightweight you better make merging great also.
I won’t go into the guts of git that enables some of this capability in this talk, but if you are interested I will highlight some resources at the end of the talk where you can go deeper.
© 2003 Microsoft Corporation. All rights reserved.
This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.

31. A Local Git project has three areas
Unmodified/modified Files
Staged Files
Committed Files
Note: working directory sometimes called the “working tree”, staging area sometimes called the “index”.

32. Git file lifecycle

33. Basic Workflow Modify files in your working directory.
Stage files, adding snapshots of them to your staging area.
Do a commit, which takes the files as they are in the staging area and stores that snapshot permanently to your Git directory.
Notes:
If a particular version of a file is in the git directory, it’s considered committed.
If it’s modified but has been added to the staging area, it is staged.
If it was changed since it was checked out but has not been staged, it is modified.

34. Aside: So what is github?
GitHub.com is a site for online storage of Git repositories.  
Many open source projects use it, such as the Linux kernel.  
You can get free space for open source projects or you can pay for private projects.
Question: Do I have to use github to use Git?
Answer: No!
you can use Git completely locally for your own purposes, or
you or someone else could set up a server to share files, or
you could share a repo with users on the same file system.

35. Get ready to use Git!
1. Set the name and for Git to use when you commit:
$ git config --global user.name “Bugs Bunny”
$ git config --global user.
You can call git config –list to verify these are set.
These will be set globally for all Git projects you work with.
You can also set variables on a project-only basis by not using the --global flag.

36. Create a local copy of a repo
2. Two common scenarios: (only do one of these)
a) To clone an already existing repo to your current directory:
$ git clone <url> [local dir name]
This will create a directory named local dir name, containing a working copy of the files from the repo, and a .git directory (used to hold the staging area and your actual repo)
b) To create a Git repo in your current directory:
$ git init
This will create a .git directory in your current directory.
Then you can commit files in that directory into the repo:
$ git add file1.java
$ git commit –m “initial project version”

37. others: init, reset, branch, checkout, merge, log, tag
Git commands
command
description
git clone url [dir]
copy a git repository so you can add to it
git add files
adds file contents to the staging area
git commit
records a snapshot of the staging area
git status
view the status of your files in the working directory and staging area
git diff
shows diff of what is staged and what is modified but unstaged
git help [command]
get help info about a particular command
git pull
fetch from a remote repo and try to merge into the current branch
git push
push your new branches and data to a remote repository
others: init, reset, branch, checkout, merge, log, tag

38. Committing files
The first time we ask a file to be tracked, and every time before we commit a file we must add it to the staging area:
$ git add README.txt hello.java
This takes a snapshot of these files at this point in time and adds it to the staging area.
To move staged changes into the repo we commit:
$ git commit –m “Fixing bug #22”
Note: To unstage a change on a file before you have committed it:
$ git reset HEAD -- filename
Note: To unmodify a modified file:
$ git checkout -- filename

39. Pulling and Pushing Good practice:
Add and Commit your changes to your local repo
Pull from remote repo to get most recent changes (fix conflicts if necessary, add and commit them to your local repo)
Push your changes to the remote repo
To fetch the most recent updates from the remote repo into your local repo, and put them into your working directory:
$ git pull origin master
To push your changes from your local repo to the remote repo:
$ git push origin master
Notes: origin = an alias for the URL you cloned from
master = the remote branch you are pulling from/pushing to, (the local branch you are pulling to/pushing from is your current branch)
$ git remote -v
origin (fetch)
origin (push)

40. Branching To create a branch called experimental:
$ git branch experimental
To list all branches: (* shows which one you are currently on)
$ git branch
To switch to the experimental branch:
$ git checkout experimental
Later on, changes between the two branches differ, to merge changes from experimental into the master:
$ git checkout master
$ git merge experimental
Note: git log --graph can be useful for showing branches.
Note: These branches are in your local repo!