Software Process

The structure of a Waterfall Process is as follows:

- Requirements
- Design
- Code
- Integration
- System Test
However, this process spans over the entire project
duration.
The Iterative Process has a similar structure
except that each process is a miniature version of
the Waterfall Process. Each process is 1-iteration
long. The Iterative processes apply the waterfall
steps iteratively.
2 iterative processes: RUP & XP.
The advantage of the Iterative Process over the
Waterfall Process is:
1) Waterfall process assumes plan is clear
from the start, this will not allow the design
team to make changes easily.
2) Iterative Process can handle uncertainty.

to revise and improve parts of the system. It

does not presuppose incremental development
but works very well with it. The difference is
that an increment may actually ship, whereas
an iteration is examined for modification.
The iterative process is described as an Agile
Processes!
Individuals & Interactions
Working software
Customer collaboration
Responding to change

Process & Tools

Comprehensive documentation
Contract negotiation
Following a plan

The Rational Unified Process (RUP)

[framework]:
- A well-defined and structured software
engineering process.
- A process product providing a
customizable process framework.

Earlier iterations should address the greatest risks

in the project. Each iteration produces an
executable release, an additional increment of the
system.
The fundamental differences between an
incremental development and a iterative
development:
- Incremental Development: It means a
staging and scheduling strategy in which
the various parts of the system are
developed at different times or rates, and
integrated as they are completed.
- Iterative Development: It means a rework
scheduling strategy in which time is set aside

The 4 RUP phases:

1) Inception: Understand what product to
build.
a. Prepare vision document and initial
business case
i. Include risk assessment and
resource estimate

b. Develop high-level project

requirements
i. Use-case and domain
models
c. Mange project scope
i. Reduce risk by identifying
all key requirements
ii. Acknowledge that
requirements will change
2) Elaboration: Understand how to build the
product.
a. Detail requirements (~80%)
b. Produce an executable and stable
architecture (10%)
c. Verify architectural qualities
i. Reliability & Scalability
d. Continuously assess business case,
risk profile and development plan
3) Construction: Build the product.
a. Complete requirements and design
model.
b. Design, implement and test each
component.
c. Build daily or weekly with
automated build process.
d. Test each build.
i. Automate regression testing
e. Deliver fully functional software
(beta release).
f. Produce release description.
4) Transition: Validate & Deploy the
product.
a. Product incremental bug-fix
releases.
b. Update user manuals and
deployment documentation.
c. Update release descriptions.
d. Execute cut-over.
e. Conduct post-mortem project
analysis.

RUP Best Practices:

- Adapt the process
- Balance stakeholder priorities
- Collaborate across teams
- Demonstrate value iteratively
- Elevate the level of abstraction
- Focus continuously on quality

Extreme Programming (XP) [agile process]:

A set of values, principles and practices for rapidly
developing high-quality software that provides the
highest value for the customer in the fastest way
possible. Most useful when plan is completely
unclear.

The 5 values:
1.
Communication
2.
Simplicity
3.
Feedback
4.
Courage
5.
Respect
The 12 practices:
- Fine Scale Feedback
o PP
o Planning Game
o Test Driven Development

o Whole team
Continuous Process
o Continuous Integration
o Design Improvement
o Small Releases
Shared Understanding
o Coding standards
o Collective Code ownership
o Simple Design
o System Metaphor
Programmer Welfare
o Sustainable Pace

XP does not mean NO documentation

XP focuses on code products
Automated Test
System code
Other products should be produced if
Necessary for the system
Helpful in producing code
Typical non-code products
Open bug graph
Task List and completion graph
Risk List
Roles in XP:
The Customer:
o Drives the project.
The Developer:
o Estimates his own work.
o Turn customer stories into working
code.
The Coach
o Guides and mentors the team
The Tracker
o Keep track of the schedule
o Collect metrics

A single process CANNOT fit all!

The strength of the process depends on various

factors such as: Project Size, Team Distribution
and Complexity of Technology. No one-size-fit-all
process.

Project Management
Project Lifecycle:

What to manage in a project: Cost, Time, Scope,

and Quality.
How to plan for a project:
1) Define Scope
a. Functionality
b. Usability
c. Reliability
d. Performance
e. Supportability
2) Decide Process
3) Define work breakdown structure
a. Define and organize the total scope
of a project. Task > Sub-Task >
Sub-Sub-Task
4) Create Schedule
a. Define Activities
b. Sequence Activities
c. Allocate Resources
d. Estimate Duration
e. Develop Schedule
5) Estimate Cost
6) Analyze Risk

Critical Path:
Activities that are critical to the completion of the
project
Any delay on an activity on the critical path
directly impacts the completion date.
The critical path refers to the path that has the
longest duration in terms of days. If you need to
identify a critical path in the exam, please make
sure to make it clear.

Staffing the Project:

- Number of people required
- Match peoples skills to the task
- Minimize conflicts
Resource Allocation:
Allocate sensibly:
- Bar chart with the people name
- Looking for gross allocation clashes
o People can only spend 100% of
their time
o A machine cannot be in two places
at the same time
Two types of dependencies
- Logical / Task dependencies
o Equipment resources may be tied to
other tasks and not available yet.
- Staff dependencies
o A delay in project may cause a
specialist to be not available, thus
delaying another project
Update resource allocations in light of experience
Have a staff allocation chart

Estimate Effort:
- Analogous Estimating
o Use actual duration of a previous,
similar activity as the basis
- Expert Judgment
o Wideband Delphi
Consensus-based estimation
technique for estimating
effort
- Use Case Points
o A software technique used to
forecast the software size for
software development.
A realistic schedule allows for:
- Meetings, client issues
- Learning, training, down time
- Test Planning, Testing & documentation
- People, process, tech to go wrong
Things to consider:
Milestones
- End point of some activity, logically
speaking, do not put it halfway through
coding
- Needs to be checked
- Start and end ceremony
o Demo of build (start)
o Report to management (end)
- Avoid milestones being too frequent or
infrequent
Buffer
- Individual task?
- Whole project?
Fixing schedule problems:
Work harder
- OT everyday
- Breaks down quickly
Hire more people
Re-scope

Admit defeat. Be more sensible.

Better to have something than nothing.

Bad Scheduling / Estimation:

- Estimates are never updated and improved
from the prev iteration
- Task are too long a duration
- Task are too general
- Task that has nobody assigned to it
o The whole team is assigned to it:
No collective ownership.
- Same tasks for all iteration / Generic Taks
o Nobody knows what is suppose to
be done
- Schedule done on a week basis / not a task
basis
Time boxing VS Feature boxing
Time boxing:
Iterate in fixed length of time.
- OK to slip some functionality
- Not OK to change the end date of an
iteration
- Figure our what the real requirements are
- Build-Feedback-Adapt cycles
Feature boxing:
Iterate with fixed number of feature
- Change the end date of an iteration just to
make sure all features are completed
Risk Management Strategies:

Example of Bad Risks:

1) Overlapping of work done by team
members
2) Different coding style by each team
member
3) Nobody has the latest copy of the code
4) Members not delivering tasks assigned on
time, delaying the schedule.
5) Dont meet requirements due to lack of
planning
6) Cannot complete on time due to too big a
scope
7) System crash due to poor maintenance
8) Out of scope / digression because team
never follow plan
9) Fails to manage risks after submitting
project plan.
GQM:
G- Goal: what should be improved
Q- Question: what details can we ask about the
process
M- Metric: what numbers can we put on the
question
It is a top-down method for creating metrics
program. Good aligning measurements with
business goals.

GQM Steps:
1) Select a project goal
2) For each goal, ask questions
3) Identify measures / metrics
4) Use it to improve the process
* Metrics are measurable and are things that DO
affect your project

Sub-VersioN
Lock-Modify-Unlock Solution:
Allows one person to change a file a time
Copy-Modify-Merge Solution:
Each user gets a personal working copy from the
server. Users work in parallel, modifying their
private copies. The private copies are merged
together into a new final version.

Work Cycle:

DONTS
Do not commit using someone elses account
Do not zip up files and check into SVN
Do not check in IDE-specific files -> will create
conflicts.
Do not copy one SVN directory into another SVN
directory

Do not indiscriminately delete files or change the

directory structure of a SVN repo.
DO not commit unnecessary files
DO not move your entire project to a new
directory in SVN just before final submission
- Will loose all prev history

Web Usability
What is Usability?
- Quality
- Learnability
- Efficiency
o Productivity
- Memorability
o Little re-learning required
- Errors
- Satisfaction
o Pleasurable
- Fuzzy and hard to quantify
o Usability tests required

Evaluation Techniques:
Cognitive Walkthrough:
- Designer plays part of user
- Check task flow and memory demands
Heuristic Evaluation: (Low-cost UI evaluation)
- Usability experts evaluate design These
experts are usually people in the same
company.
User Tests:
- Observe actual users using the system
- Beware of small sample size!

Bad UIs are ones with too much buttons and little
or no instructions.

Software Testing
Software Quality Management (SQM)
- Product Quality
o Meeting customers needs and
expectations
- Process Quality
o Effectiveness and efficiency of
development process
- Good Process is needed to produce good
products

Pretty != easy

Software quality control techniques

UI design process:

Types of test:
1) Functional Test
a. Expected results is correct
2) Non-Functional Test
a. Performance Test
i. Checks to see if the
application can handle large
quantities of data or users.
b. Usability Test
i. Checks if the UI is easy to
use and understand.
3) Black Box
a. Test functionality of module as a
whole
b. Input / Output tests with no specific
code tests.

Good UIs = USABLE UIs = Success / critical to

software sales!
Users > Use it > Buy it. A good UI will attract
buyers.

4) White Box
a. Tests the inner workings of a
module
b. Code level test
5) Regression Test
a. To ensure that defects have not
been introduced as a result of the
new changes
* Essentially the difference between white and
black box testing are not the tools used, but
rather the objective in mind. Hence, for example,
we cannot call the Auto-JSON checker a tool
that belongs to the black or white box testing. If
we intend to test the output accuracy solely based
on the actual outputs against the prepared outputs,
then it would be a black-box testing. If we are
preparing test cases to specifically test the codes
flow [i.e. whether it enters the if-statement or the
else-statement], then this is a white-box testing.

Stages of testing:
Implementation -> Unit test
- Verify the smallest testable elements of the
software. Checks for UI, logic, corner
cases as well as error cases. Uses unit
testing framework [JUnit / NUnit]

Testing -> Integration test, System test, System

Integration test, UAT [performed by users hence
test is different].
- Integration Test: Individual software
modules are combined and tested as a
group. [Regression Testing]
- System Test: Test a completely integrated
system to verify that it meets its
requirements.
- System Integration Test (SIT) verifies that
a system is integrated to any external or

third party systems defined in the system

requirements.
UAT final test prior to deployment
o Alpha Testing clients, developers
o Beta Testing any potential
customers who agree to use the
system and report problems to the
system.

Debugging -> To detects defects related to design

or the actual writing of the source code.

property [Atomic, Consistent, Isolated and

Durable].

http://www.sis.smu.edu.sg/aboutschool/overview.asp

A: The transaction is either completed executed or

not at all.
C: Only valid data is in the database before and
after the transaction is performed
I: Intermediate data is invisible while a transaction
is taking place
D: If a transaction succeeds, the data remains even
if the database crashes.

Red: Access Method

Green: Server Name
Blue: What to display
Mapping between URL & Web Directory:

Low Level Design

Why Index? Cause it is an effective way of
retrieving a desired subset of data. What is an
index? It is an auxiliary data structure that allows
fast access to the rows in a database. It is created
using one or more columns of the table.
Used on larger tables with more than 10,000 rows.
Things indexed:
1) Primary key(s)
2) Search Fields
3) Fields in SQL Order By / Group By
Avoid use of indexed for fields with long values.
DBMS may have limit on the number of indexes
per table and number of bytes per indexed field(s).
Null values may not be referenced from an
index. Use indexes heavily for non-volatile
databases. Modifications (where database are
frequently experiencing inserts & deletes) require
updates to occur in index files
Transaction is a discrete unit of work that must be
completely processed or not processed at all. IT
might involve multiple updates, however, if 1
update fails, than all other updates must be
cancelled. A transaction must keep to the ACID

Connection Pooling:
1) Creates multiple connection and store them
in a pool
2) Application requests for a connection from
the pool
3) Application uses the connection to
communicate with the database
4) Application returns the connection back to
the pool
5) Close all the connections when the
application is shut down

JavaServerPages:
GET: data sent is appended to end of the URL in
the browser. More importantly, it can be
bookmarked! The amount of form data is also
small. The processing has no side-effect on the
server
POST: The processing changed the stat of the
server. The amount of form data is large and that it
should not be appended to the URL. Useful for
sending things like password over.

JSP Pages can contain text, just like normal

HTML files.
JSP Directive:
<%@ page import=java.util.*%>
Comment:
<%-- comment here --%>
The above JSP comment is not seen by the client.
<!comment here
The above HTML comment is sent to the client as
a response, but is ignored by the browser when
displaying the HTML.
What are Implicit Variables?
They are objects that are predefined and available
to JSP page developers for direct use.
<%! Codes here %>

The above is a JSP declaration for declaring new

objects (i.e DecimalFormat or method blocks)
JSP Summary:

Sending data: Internal VS External:

Internal:
// JSP tag (part of HTML)
<jsp:forward page=<localURL>/>
// scriplet
RequestDispatcher rd =
request.getRequestDispatcher(<localURL?);
rd.forward(request,response);
External:
//scriplet
response.sendRedirect(<URL>);
The difference is in the URL change. Using the
internal way, the URL does not reflect the change;
this is because the browser does not know that a
change took place. External method will cause a
change in the URL as the browser is aware of the
changes.
HTTP is stateless as each request is independent.

Therefore, we store in session. Contents stored in

session remains through out the duration that the
user is still active on the browser. Unlike request,
the user can move around the application and the
data stored in session would remain.
How to terminate the session:
Server-side:
- Use these two methods:
setMaxInactiveInterval() / invalidate()
- Session-config element in web.xml
Client-side:
- Not returning to site
- Flush browsers cookie cache
- Shutting down browser
JSP Include Action Tag:
<jsp:include page=<localURL>/>
The above syntax allows one to compile more than
1 page at the time. The compilation is done
separately. If one page fails, the other page still
compiles perfectly.
Include Directive
<%@include file=<localURL>%>
The above syntax will compile the two jsp(s)
together as one. If one page fails, so does the other
page. Variables declared in one page cannot be
used in the page that the file is being declared in.
JSP Design
JSP Access Model 1:
The view and controllers are all JSPS.
Servlet vs JSP:

Frameworks:
Web App:
- Struts
- Spring
- Stripes
Persistence:
- Java Persistence API (JPA)
- Java Data Objects (JDO)
- Objectify

JSP Access Model 2: MVC

The model 2 access model is the access model that
realize the MVC model. The Model 2 architecture
is an approach that uses both servlets and JSP to
build web application. It uses JSP to generate the
presentation layer and servlets to perform processintensive tasks. Here, the servlet acts as the
controller and is in charge of the request
processing and the creation of any beans or objects
used by the JSP, as well as deciding, depending on
the user's actions, which JSP page to forward the
request to.
There is no processing logic within the JSP page
itself. The page basically retrieves objects
previously created by the servlet, and extracting
the dynamic information from these objects for
insertion within static templates.

This led to a clean separation of presentation from

content. The leading to clear delineation of the
roles and responsibilities of the developers and
page designers on your programming team. In fact,
the more complex your application, the greater the
benefits of using the Model 2 architecture should
be.
Struts 1:
1. When the user clicks on a link or click on
the submit button of a form in a HTML
page, the browser sends a HTTP request to
the server.
2. The request is received by the
ActionServlet. The struts-config.xml file
read by the ActionServlet upon loading.
This file contains a set of mappings which
is used by the ActionServlet to identify
which Action class should be used to
process this request.
3. The ActionServlet then delegates it to the
specific Action class to perform the
necessary business logic.
4. The Action class performs its logic on the
Model components associated with the
application. This includes using a set of
JavaBeans to retrieve data from the
database.
5. This set of JavaBeans, termed as
DataManagers because they interact with
the data stores, then instantiates the
JavaBeans that contains the data and
business logic.
6. It then place the necessary information JavaBean(s) in the HttpServletRequest
object so that it can be picked up by the
JSP page later on.
7. Once the Action has completed its
processing, it returns control to the
ActionServlet. As part of the return value,

the Action class returns a key that indicates

the result of the its processing.
8. The ActionServlet then forward the request
to a JSP page that was linked to the
returned key for presentating the data to the
user.
9. The JSP retrieves the JavaBeans from the
request object, and pull out the relevant
data.
10. It then formats the data and output the
HTML to the user.
The Pros of using a Web App Framework:
- Provides MVC out of the box
- Provides client & server input validations
using a common config file
- Supports Internationalization easily
Summary of JSP Access Model 1 & 2: