What is Analysis?

Analysis emphasizes an investigation of the problem and requirements, rather than a

solution.

For example: - In an online trading system, we analyze

How will it be used?

What is its function?

Requirement analysis An investigation of the requirements

Object oriented analysis An investigation of the domain objects.

In object oriented analysis there is an

emphasis on finding and describing

the objects or concepts in the problem

domain

What is Design?

Design emphasizes a conceptual solution that fulfills the requirements rather than its

implementation.

For example: - description of database schema and software objects.

In object oriented design there is an emphasis on defining s/w objects and how they

collaborate to fulfill the requirements.

Basic terms in OOAD

1. Use case

Use case includes stories or scenarios of how people use the application. It's a popular

tool in requirements analysis.

Example: -

Play a Dice Game use case

Player requests to roll the dice. System presents results. If the dice face value totals

seven, player wins; otherwise, player loses.

2. Domain Model

Domain model is a visualization of the concepts (or mental objects) of a real world

domain. It is also called conceptual object model.

3. Sequence Diagram

A sequence diagram shows the flow of messages between software objects, and thus the

invocation of methods. It provides a dynamic view of collaborating objects. It is a kind

of UML interaction diagram.

4. Design class diagram

Design class diagram shows a static view of the class definitions. It shows software

classes. It illustrates the attributes and methods of the classes.

What is Artifact?

Tangible byproduct produced during the development of software. Example: Use case

diagrams, Class diagrams.

What is UML?

UML is a visual language for specifying, constructing and documenting the artifacts of

the systems. It is the de-facto standard diagramming notation for drawing or presenting

pictures related to software, especially object oriented software.

Three ways to apply to UML

UML as sketch: - Informal and incomplete diagrams often hand sketched on

whiteboards. Agile modeling emphasize UML as sketch.

UML as blueprint: - Relatively detailed designed diagram used either for reverse

engineering or for code generation.

UML as programming language: - Complete executable specification of a software

system in UML.

Three perspectives to apply UML

1. Conceptual perspective: -The diagrams describe things in a situation of the real world or domain of interest.

2. Specification perspective: -The diagrams describe software abstractions or components with specifications and interfaces, but no commitment to a particular

implementation.

3. Implementation perspective: -The diagrams describe software implementations in a particular technology(such as Java)

Types of classes

1. Conceptual class:- Class representing a real world concept or thing 2. Software class: - Class representing a specification or implementation

perspective of a software component.

3. Implementation class: - A class implemented in a specific OO language.

What is software development process?

It describes an approach to building deploying and possibly maintaining software.

Examples: Unified Process (UP), Extreme Programming (XP), Scrum

What is Unified Process (UP)?

The Unified Process is a popular iterative software development process for building

object oriented systems.

UP is very flexible, open and encourages including skillful practices from other iterative

methods into it. For example, the practices like test driven development, re-factoring and

continuous integration of Extreme Programming (XP).It also include the practice of

scrum such as common project room and daily meeting practice.

What is Iterative and Evolutionary Development?

In this life cycle approach, the development is organized into a series of short, fixed-

length mini projects called iterations. The outcome of each iteration is tested, integrated

and executed. Each iteration includes its own requirements analysis, design, and

implementation and testing activities. The iterative lifecycle is based on the successive

enlargement and refinement of the system through multiple iterations with cyclic

feedback and adaptation as core drivers. The system grows incrementally over time,

iteration by iteration. Thus this approach is also known as iterative and incremental

development. Since the feedback and adaptation evolve the specifications and design, it

is also known as iterative and evolutionary development.

Changes in iterative development

Unlike Waterfall model, changes reflect in the system quickly because of feedback and

adaptation. Each iteration involves choosing a small subset of requirements, quick

design, implementation and testing. The changes appear in the developed system gives a

clear idea to the user about the system they really needs. Since it is a series of structured

build-feedback-adapt cycles, the deviation from the actual path will be less in the later

iterations compared to early ones.

Benefits of Iterative development

1. Less project failure, better productivity and lower defect rates.

2. Early rather than late mitigation of high risks.

3. Early visible progress.

4. Early feedback, user engagement and adaptation.

5. Manage complexity.

6. Improves the development process.

Length of iterations

Most iterative methods recommend iteration length between 2 to 6 weeks. Small steps,

rapid feedback and adaptation are the central ideas in iterative development. Long

iterations increases the project risk. A very long time boxed iterations misses the point of

iterative development. Short is good.

Waterfall life cycle

Waterfall life cycle defines all or most of the requirement before programming. It creates

a thorough design before programming.

Reasons for failure of waterfall

A study on typical software project has showed that the software development is a

domain of high change and instability. Thus waterfall life cycle which is based on the

assumption that things are long term stable is fundamentally flawed.

Types of Iterative planning

Risk-driven: -Identify and drive down the highest risks.

Client-driven: -Build visible features that the client cares most about.

Agile development methods

Agile development methods usually apply timeboxed iterative and evolutionary

development ,employ adaptive planning, promote incremental delivery and include other

values practices that encourage agility(rapid and flexible response to change).

Agile Manifesto

Individuals and interactions over processes and tools

Working software over comprehensive documentation.

Customer collaboration over contract negotiation.

Responding to change over following a plan.

The Agile Principles

1. The highest priority is to satisfy the customer through early and continuous delivery of valuable software.

2. Always welcome change in the requirements even late in the development.

3. Deliver working software frequently.

4. Business people and developers work together daily throughout the project.

5. Build projects around motivated individuals.

6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

7. Working software is the primary measure of progress.

8. Agile processes promote sustainable development.

9. The sponsors, developers and the users should be able to maintain a constant pace.

10. Continuous attention to technical excellence and good design enhances agility.

11. Simplicity the art of maximizing the amount of work not done.

12. The best architectures, requirements and designs emerge from self-organizing teams.

13. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Agile Modeling

Agile modeling implies the following practices and values: -

Adopting an agile method does not mean avoiding any modeling.

The purpose of modeling and models is primarily to support understanding and communication, not documentation.

Model and apply the UML for the smaller percentage of unusual, difficult, tricky parts of the design space.

Use the simplest tool possible

Dont model alone, model in pairs or triads.

Create models in parallel.

Use simple notation while sketching with a pen on whiteboards.

Remember, all models will be inaccurate, and the final code or design differs from the model.

Developers should do the OO design modeling.

Agile UP

Agile Unified Process is a simplified version of the Unified Process. It describes a simple, easy to understand approach to developing business application software

using agile techniques and concepts. The approach applies agile techniques

include test driven development (TDD), Agile Model Driven Development

(AMDD), agile change management, and database refactoring to improve the

productivity.

Agile UP prefers small set of UP activities and artifacts.

Focus on early programming. Not in early documentation.

Apply UML with Agile modeling practices.

In Agile UP, there is no detailed plan for the entire project. Only one iteration in advance is planned (called Iteration Plan). Detailed planning is done adaptively

from iteration to iteration.

Unified Process Phases

A UP project organizes the work and iterations across four major phases: -

1. Inception: - approximate vision, business case, scope, vague estimates.

2. Elaboration: - refined vision, iterative implementation of the core architecture, resolution of high risks, identification of most requirements and scope, more

realistic estimates.

3. Construction: - iterative implementation of the remaining lower risk and easier elements, and preparation for deployment.

4. Transition: - beta test, deployment.

UP Disciplines

A set of activities and related artifacts in one subject area, such as the activities within

requirements analysis. In the UP an artifact is the general term for work product: code,

Web graphics, database schema, text document, diagrams, models and so on. There are

several disciplines in UP. Some of them are: -

Business modeling: - The domain model artifact to visualize noteworthy concept in the application domain.

Requirements: - The Use-Case model and Supplementary Specification artifacts to capture functional and non-functional requirements.

Design: - The Design Model artifact, to design the software objects.

Inception

Inception is initial short step to establish a common vision and basic scope for the

project. The purpose of the inception phase is not to define all the requirement or

generate a believable estimate or project plan. Some of the questions asked during the

inception phase are:

What is the vision and the business case for this project?

Feasible?

Buy and/or build?

Rough unreliable range of cost.

Should we proceed or stop.

Requirements

Requirements are capabilities and conditions to which the system or the project must

conform.

A prime challenge of requirements analysis is to find, communicate and remember what

is really needed, in a form that clearly speaks to the client and development team

members.

Types and Categories of Requirements

Based on FURPS+ model: -

Functional features, capabilities, security.

Usability human factors, help, documentation

Reliability frequency of failure, recoverability, predictability

Performance response times, throughput, accuracy, availability, resource usage

Supportability adaptability, maintainability, internationalization,

configurability

The sub-factors include the following: -

Implementation resource limitations, language and tools, hardware

Interface constraints imposed by interfacing with external systems.

Operations system management in its operational setting.

Packaging for example, a physical box

Legal licensing and so forth

Use cases

Use cases are test stories, widely used to discover and record requirements. The

influence many aspects of a project including OOA/D and will be input to many

subsequent artifacts in the case studies.

Example:-

Process Sale

A customer arrives at a checkout with items to purchase. The cashier uses the POS

system to record each purchased item. The system presents a running total and line-item

details. The customer enters payment information, which the system validates and

records. The system updates inventory. The customer receives a receipt from the system

and then leaves with the items.

What are Actors, Scenarios and Use Cases?

An actor is something with behavior such as a person, computer system or organization.

A scenario is a specific sequence of actions and interactions between actors and the

system.

A use case is a collection of related success and failure scenarios that describe an actor

using a system to support a goal.

A use case model is the set of all written use cases; it is a model of the systems functionality and environment.

What are three kinds of Actors?

Primary actor Has user goals fulfilled through using services of the system under discussion. Eg:- the cashier.

Supporting actor Provides a service to the system under discussion. Eg:- automated payment authorization service.

Offstage actor Has interest in the behavior of the use case, but is not primary or supporting. Eg:- Government tax agency

What are three common use case formats?

brief One paragraph summary

casual Informal paragraph format

fully dressed All steps and variations are written in detail

Use Case Diagrams

Use case diagrams are used to illustrate the names of use cases and actors and the

relationship between them.

Other Requirements Artifacts

Supplementary Specification captures and identifies other kinds of requirements such as reports, documentation, packaging, supportability, licensing

and so forth.

Glossary captures terms and definitions

Vision summarizes the vision of the project

Business Rules capture long living and spanning tree rules or policies such as tax laws.