Business Analyst Study Material
Business Analyst Study Material
Business Analyst Study Material
1
Business Analysis
Business Analysis is one of the most important steps in developing a software
solution. It is crucial in identifying the business needs of customers and other
stakeholders in order to determine appropriate solutions to their business
problems.
2
The websites maintained by the competitors
Defining and scoping the project - Before he can begin to gather the
actual requirements, a business analyst needs to ensure that the scope of
the project is clear and complete. This involves understanding why the
project has been initiated and the goals of the project. A complete project
scope will name and define all the entities that are involved with the project.
This includes people, systems, internal departments, vendors and customers.
It should also include a high-level description of the business processes that
will be covered as part of the solution and a list of items that will not be
included.
3
Gathering requirements is an iterative process. In addition to identifying the
requirements, the business analyst also needs to prioritize them to ensure
that the most critical issues are addressed first.
4
During this stage, a business analyst needs the following skills:
Presentation skills
Writing skills to create clear email messages, memos and status
reports
Conducting comprehensive requirements reviews
Verifying that the solution meets the requirements - Even after the
technical team takes over the project, the business analyst continues to
remain involved in order to ensure that:
The technical design meets business requirements and usability standards.
The developed software meets the project goals. The final product passes
quality assurance tests and user acceptance.
It is evident from the above that business analysis plays a critical role in the
success of a software project from the start to the finish. The business
analyst plays an important role in every stage of the software development
life cycle and in ensuring that the solution that emerges out of the whole
process meets the business goals of all the stakeholders involved.
5
REQUIREMENTS
There are basically two types of software requirements — Functional and
Non-Functional.
Functional Requirements
Functional requirements describe the functionality of the product. They
describe exactly what tasks the software must perform. Functional
requirements define the scope of the system, the product boundaries, and its
connections to adjacent systems. Functional requirements also define the
business rules. Business rules are the rules that the system must conform to,
based on the individual business. This includes defining the data that must be
tracked. The business rules are the most important type of functional
requirements and most of your requirements will be of this type.
Non-Functional Requirements
Non-Functional requirements describe the look and feel of the system. This
includes the visual properties of the system, its usability, and the
performance requirements – how big, how fast, etc. Non-Functional
requirements also include the product‘s intended operating environment
and any maintainability, portability and security issues. Non-Functional
requirements also include cultural and political issues as well as legal
requirements that the software must conform to.
It‘s important to point out that various sources, such as books and Web sites,
describe the different types of software requirements using other categories,
often with contradictory terminology. The important part, however, is not
which category the requirements fall into, but that all the requirements in the
business process have been identified and documented.
6
Looking at the above list, it‘s obvious that quality and accuracy are extremely
important. One way to assure quality is to create a single checkpoint that
each requirement must pass through.
So, where and how do we find out about the requirements for a system? The
best places are from:
Domain Experts – people who are very knowledgeable and work in the
area of the system that is being built
Users – people who will actually be the ones using the system once it‘s
built
Existing processes and programs – both manual processes and existing
programs
o Find out the limitations of existing systems and software
o Find out where the users‘ time is spent
o Find out what they like and don‘t like
o Sit down with the users WHILE they are performing their tasks.
Be sure to ask questions to get a clear idea of what they are
doing.
Review similar software programs – if there is a similar or competing
program, this can be a great resource
So, now we know what information we are looking for and we know where to
get it. The next items we‘ll discuss are the various methodologies for
collecting requirements. These techniques include cards, simple requirement
lists, matrices and templates, as well as complex software programs for
requirements management. Often, a combination of techniques works the
best, since each method has strengths and weaknesses.
7
Once this list has been compiled, the next step often is to create a
Requirements Trace Matrix. This matrix simply takes the list of
requirements, grouped by category, and puts them into a matrix that has
other information
8
Software Engineering
Software engineering is the practice of using selected process techniques to
improve the quality of a software development effort. This is based on the
assumption, subject to endless debate and supported by patient experience,
that a methodical approach to software development results in fewer defects
and, therefore, ultimately provides shorter delivery times and better value.
The documented collection of policies, processes and procedures used by a
development team or organization to practice software engineering is called
its software development methodology (SDM) or system development life
cycle (SDLC).
Moving through the development life cycle the following major steps might
be encountered:
Project charter and business case
Definition of the business process and business requirements
Documentation of user, functional and system requirements
Top level architecture, technical approach, and system design
System decomposition into component and unit specifications and
design
Coding, unit test planning, and unit test
Generation of test data for unit testing and system testing
System integration and testing
Implementation, delivery and cut-over
Training and user support
System upgrades and routine software maintenance
9
Quality management (quality assurance, quality reviews, defect
tracking)
System engineering reviews (requirements review, prelim. and critical
design reviews, etc.)
Support environment (development tools, libraries, files management,
data management)
Written guidance for all these steps would constitute the core of the
methodology. It wouldn't take long to fill a number of big binders with
development processes and procedures. Hence, the importance of selecting
processes wisely - to address known risks - keeping the methodology
streamlined, and allowing for some discretion on the part of the project
team.
10
Systems Development Life Cycle (SDLC)
The systems development life cycle (SDLC) is a conceptual model used in
project management that describes the stages involved in an information
system development project, from an initial feasibility study through
maintenance of the completed application.
11
In general, an SDLC methodology follows these steps:
5. The system is put into use. This can be done in various ways. The new
system can be phased in, according to application or location, and the
old system gradually replaced. In some cases, it may be more cost-
effective to shut down the old system and implement the new system
all at once.
12
The image below describes the various phases involved in the Software
Development Life Cycle.
Feasibility
The feasibility study is used to determine if the project should get the go-
ahead. If the project is to proceed, the feasibility study will produce a project
plan and budget estimates for the future stages of development.
Implementation
In this phase the designs are translated into code. Computer programs are
written using a conventional programming language or an application
generator. Programming tools like Compilers, Interpreters, Debuggers are
used to generate the code. Different high level programming languages like
13
C, C++, Java are used for coding. With respect to the type of application, the
right programming language is chosen.
Testing
In this phase the system is tested. Normally programs are written as a series
of individual modules, these subject to separate and detailed test. The
system is then tested as a whole. The separate modules are brought together
and tested as a complete system. The system is tested to ensure that
interfaces between modules work (integration testing), the system works on
the intended platform and with the expected volume of data (volume testing)
and that the system does what the user requires (acceptance/beta testing).
Maintenance
Inevitably the system will need maintenance. Software will definitely undergo
change once it is delivered to the customer. There are many reasons for the
change. Change could happen because of some unexpected input values into
the system. In addition, the changes in the system could directly affect the
software operations. The software should be developed to accommodate
changes that could happen during the post implementation period.
14
SDLC Methodologies
WATERFALL METHODOLOGY
This presumes that the system requirement have already been defined and
scrubbed exhaustively, which is probably the most important step towards
project success. Nevertheless, the graphic illustrates a few critical principles of a
good methodology:
Work is done in stages,
Content reviews are conducted between stages, and
Reviews represent quality gates and decision points for continuing.
15
The waterfall provides an orderly sequence of development steps and helps
ensure the adequacy of documentation and design reviews to ensure the
quality, reliability, and maintainability of the developed software. While
almost everyone these days disparages the "waterfall methodology" as being
needlessly slow and cumbersome, it does illustrate a few sound principles of
life cycle development.
16
SPIRAL METHODOLOGY
17
using automated tools, so outputs can contribute to generation of code
structures or help generate the code itself.
Why it works.
The spiral methodology is an incremental improvement on the waterfall
methodology. It allows for feedback to each team the complexity of each
requirement. There are stages where mistakes in the requirements can be
corrected. The end user gets a peek at the results and can feedback
information. The implementation team can feedback performance and
viability information back to the requirement team and the design team. The
product can track technology better. As new advances are made, the design
team can incorporate them into the architecture.
Spiral Strengths
Avoidance of Risk is enhanced
Minimizing Resource consumption not a priority
Experienced, highly skilled Project Manager
Strong approval and documentation control
Organization and team cultures embrace controls and precision
Can incorporate other methodologies into the Spiral framework.
Implementation has priority over functionality.
Additional Functionality can be added at a later date.
Spiral Weaknesses
Highly customized limiting re-usability
Applied differently for each application
Risk of not meeting budget or schedule
Possibility to end up implemented as the Waterfall framework
18
PROTOTYPING MODEL
The word prototype comes from the Latin words proto, meaning original, and
typus, meaning form or model. In a non-technical context, a prototype is an
especially representative example of a given category.
Prototyping is the development of an information system by delivering small
complete parts of a system. With each new implementation the application
provides additional functionality.
19
A prototype is a model, usually the first of its kind, after which future replicas
are produced.
Prototype Strengths
Strong Dialogue between users and developers
Missing functionality can be identified easily
Confusing or difficult functions can be identified
Requirements validation
Quick implementation of, incomplete, but functional, application
May generate specifications for a production application.
Environment to resolve unclear objectives
Project leader is experienced
Encourages innovation and flexible designs
Prototype Weaknesses
Prototype may not be given-up
Prototype may not have sufficient checks and balances incorporated.
Contract may be awarded without rigorous evaluation of Prototype
Identifying non-functional elements difficult to document
Incomplete application may cause application not to be used as the full
system was designed
Incomplete or inadequate problem analysis.
Client may be unknowledgeable
Approval process and requirement is not strict.
Requirements may frequently change significantly
20
RAPID APPLICATION DEVELOPMENT (RAD) METHODOLOGY
RAD Strengths
Greater flexibility for scope changes.
Being able to identify limitations earlier in the development process.
Can deliver partial functionality sooner than with the Waterfall model.
RAD Weaknesses
Not good for large projects. Would require sufficient resources to
create the right number of RAD teams.
Strong commitment required from both the developers as well as the
clients to the rapid-fire activities necessary to get the system
completed in a much-abbreviated time frame.
21
JOINT APPLICATION DEVELOPMENT (JAD) METHODOLOGY
The Joint Application Development (JAD) methodology aims to involve the
client in the design and development of an application. This is accomplished
through a series of collaborative workshops called JAD sessions. Two
employees of IBM, Chuck Morris and Tony Crawford, developed the JAD
methodology in the late 1970s and began teaching the approach in to the
1980s.
22
EXTREME PROGRAMMING (XP) METHODOLOGY
XP Core Practices
The core practices of Extreme Programming, as described in the first edition
of Extreme programming Explained can be grouped into four areas (12
practices) as follows:
Fine scale feedback
Test driven development
Planning game
Whole team
Pair programming
Continuous process rather than batch
Continuous Integration
Design Improvement (a.k.a refactor)
Small Releases
Shared understanding
Simple design
System metaphor
Collective code ownership
Coding standards or coding conventions
Programmer welfare
Sustainable pace (i.e. forty hour week)
The core practices are derived from generally accepted best practices, and
are taken to extremes.
23
Testing code is good. Therefore, in XP, tests are written before the code is
written. The code is considered complete when it passes the tests (but then it
needs refactoring to remove complexity). The system is periodically, or
immediately tested using all pre-existing automated tests to assure that it
works. See test-driven development.
XP Controversy
Detailed specifications are not created or preserved.
Programmers are required to work in pairs - not all software developers
expect to be asked to work this way.
There is no Big Design Up Front. Most of the design activity takes place on
the fly and incrementally, starting with "the simplest thing that could possibly
work" and adding complexity only when it's required by failing tests. This
could result in more re-design effort than only re-designing when
requirements change.
A customer representative is attached to the project. This role can become a
single-point-of-failure for the project and some people have found it to be a
source of stress.
24
AGILE SOFTWARE DEVELOPMENT
25
Traceability
A Traceability Matrix is used to show how work products are derived from
their inputs. For example, if the rows of a matrix are labeled with the names
of business activities and the columns are labeled with information needs, an
entry in a cell indicates that the information need was identified from the
intersecting activity.
26
Unified Modeling Language(UML)
Overview
The Unified Modeling Language (UML) is a language for specifying,
visualizing, constructing, and documenting the artifacts of software systems,
as well as for business modeling and other non-software systems. The UML
represents a collection of the best engineering practices that have proven
successful in the modeling of large and complex systems.
In the late 1980‘s and early 1990‘s, there were many often conflicting
modeling nomenclatures. In retrospect, the arguments over these differences
were based more on personal preferences than anything else, since each
method had its own strengths and weaknesses. Finally, after many disputes,
the three most respected men in this field, Ivar Jacobson (OOSE – Object
Oriented Software Engineering), Grady Booch (The Booch Method) and
James Rumbaugh (OMT – Object Modeling Technique) decided to stop the
debate and instead work together to combine their ideas and develop a
standard. The three became known as the ―three amigos,‖ and their work
became the Unified Modeling Language (UML).
UML Basics
UML models allow us to design and plan the system we will build before we
waste any time coding a faulty design. Unfortunately, many people
(programmers as well as customers) feel they aren‘t being ―productive‖
unless they‘re producing code. However, in the long run, applications that
are well-planned and built with a solid design are actually less time
consuming to build, more flexible and scalable, and easier to maintain than
systems built by trial and error. Imagine building a skyscraper (or even a dog
house) without any blueprints… Or what about something relatively simple
like having a 25- person dinner party? Planning is essential and something
we understand is necessary for most projects. However, somehow this
process is often skipped in software development!
27
of the system that is being designed. The UML doesn‘t really have a
standardized process — the notation that is used for drawing the diagrams is
standard, but the process that is followed to create the diagrams is not
actually part of the UML.
Why We Model
Developing a model for an industrial-strength software system prior to its
construction or renovation is as essential as having a blueprint for large
building. Good models are essential for communication among project teams
and to assure architectural soundness. We build models of complex systems
because we cannot comprehend any such system in its entirety. As the
complexity of systems increase, so does the importance of good modeling
techniques. There are many additional factors of a project‘s success, but
having a rigorous modeling language standard is one essential factor.
To build complex systems, the developer must abstract different views of the
system, build models using precise notations, verify that the models satisfy
the requirements of the system, and gradually add detail to transform the
models into an implementation.
28
architecture. If you want to build a shed in your backyard, you can just start
building; if you want to build a new house, you probably need a blueprint; if
you are building a skyscraper, you definitely need a blueprint. The same is
true in the world of software. Staring at lines of source code or even
analyzing forms in Visual Basic does little to provide the programmer with a
global view of a development project. Constructing a model allows the
designer to focus on the big picture of how a project's components interact,
without having to get bogged down in the specific details of each component.
In terms of the views of a model, the UML defines the following graphical
diagrams:
Use case diagram
Class diagram
Behavior diagrams:
o State chart diagram
o Activity diagram
Interaction diagrams:
o Sequence diagram
o Collaboration diagram
Implementation diagrams:
o Component diagram
o Deployment diagram
Package diagram
29
Provide a formal basis for understanding the modeling language.
Encourage the growth of the object tools market.
Support higher-level development concepts such as components,
collaborations, frameworks and patterns.
Integrate Best Practices
Actors
Actors are not part of the system—they represent anyone or anything that
must interact with the system. An actor may
Only input information to the system
Only receive information from the system
Input and receive information to and from the system
student
Use Cases
Use cases model a dialogue between an actor and the system. They
represent the functionality provided by the system; that is, what capabilities
will be provided to an actor by the system. The collection of use cases for a
system constitute all the defined ways the system may be used.
30
The formal definition for a use case is: A use case is a sequence of
transactions performed by a system that yields a measurable result of values
for a particular actor.
The following questions may be used to help identify the use cases for a
system:
What are the tasks of each actor?
Will any actor create, store, change, remove, or read information in
the system?
What use case will create, store, change, remove, or read this
information?
Will any actor need to inform the system about sudden, external
changes?
Does any actor need to be informed about certain occurrences in the
system?
What use cases will support and maintain the system?
Can all functional requirements be performed by the use cases?
MaintainSchedule
There are two types of relationships that may exist between use cases:
include and extend.
31
Multiple use cases may share pieces of the same functionality. This
functionality is placed in a separate use case rather than documenting it in
every use case that needs it.
Include relationships are created between the new use case and any other
use case that "uses" its functionality. For example, a Course Registration use
case could start with the verification of the user. This functionality can be
captured in a User Verification use case, which is then used by other use
cases as needed. An include relationship is drawn as a dependency
relationship that points from the base use case to the used use case.
include
PlaceOrder
include
ValidateOrder
include
TrackOrder
extend
ShipOrder ShipPartialOrder
What is a Class?
A class is a description of a group of objects with common properties
(attributes), common behavior (operations), common relationships to other
objects, and common semantics. Thus, a class is a template to
create objects. Each object is an instance of some class and objects cannot
be instances of more than one class. For example, the CourseOffering class
may be defined with the following characteristics:
32
Attributes—location, time offered
Operations—retrieve location, retrieve time of day, add a student to
the offering
In the UML, classes are represented as compartmentalized rectangles. The
top compartment contains the name of the class, the middle compartment
contains the structure of the class (attributes), and the bottom compartment
contains the behavior of the class (operations).
States
A state is a condition during the life of an object during which it satisfies
some condition, performs some action, or waits for an event. The state of an
object may be characterized by the value of one or more of the attributes of
the class. For example, a CourseOffering object may be open (able to add a
student) or closed (maximum number of students already assigned to the
CourseOffering object). The state depends upon the number of students
assigned to the particular CourseOffering object. Additionally, a state of an
object may be characterized by the existence of a link to another object. A
professor may be teaching or on sabbatical. This depends upon the existence
of a link to a CourseOffering object. Looking at the state of an object can
validate the multiplicity chosen for a relationship to another object. That is, if
being in a state depends upon the existence of a link to another object, this
implies that the multiplicity of the relationship modifying the role of the
associated class must include zero (i.e., the relationship is optional). Thus,
the states of an object are found by examining the attributes and links
defined for the object.
The UML notation for a state is a rectangle with rounded corners as shown
below.
OpenRegistration
33
Interfaces
An Interface is a collection of operations that specify a service of a class or a
component. An interface describes the externally visible behavior of an
element. An interface might represent the complete behavior of a class or
component or only a part of that behavior. An interface defines a set of
operation specifications but never a set of operation implementations.
IException
Components
A Component is a physical and replaceable part of a system that conforms to
and provides the realization of a set of interfaces. A component typically
represents a physical packaging of otherwise logical elements such as
classes, interfaces and collaborations. Examples of components could be
COM+ components, Java Beans as well as the source code files.
Register.exe
Node
A Node is a physical element that exists at runtime and represents a
computational resource, generally having at least some memory and, often,
processing capability. A set of components may reside on a node and may
also migrate from node to node.
Database
34
DIAGRAMS IN UML
Other use case diagrams may be created as needed. Some examples follow:
• A diagram showing all the use cases for a selected actor
• A diagram showing all the use cases being implemented in an iteration
• A diagram showing a use case and all its relationships
They are most valuable on a very large or complex system where the
interaction between Use Cases is not straightforward or easily apparent. Use
Case Diagrams are also especially useful when you have Use Cases that are
―subclassed‖ from other Use Cases. The Use Case Diagrams give you an easy
graphical way to display this inheritance.
student
MaintainSchedule
billing system
RequestCourse
Professor
MaintainCurriculum
Registrar
CLASS DIAGRAM
Class Diagrams describe the various types of objects that exist in the system
and the static relationships that exist between them. Class Diagrams also
show the attributes (properties) and the operations (methods) of a class.
35
Class Diagrams allow you to plan how the classes/objects will function and
interact. You find the classes by examining the objects in the sequence and
collaboration diagrams.
STATECHART DIAGRAM
State Diagrams describe the behavior of a system. They show all the possible
states an object can get into, and also how the object‘s state changes as a
result of events that happen to it. Usually, State Diagrams are drawn to show
the lifetime behavior of a single class. The large black dots indicate the
starting and ending points of the events. State transition diagrams are drawn
for objects that typically have a lot of dynamic behavior.
ACTIVITY DIAGRAMS
Similar to a flow chart, Activity Diagrams describe the sequencing of
activities. They are actually a variant of the State Diagram. Like State
Diagrams, the starting point is indicated with a large black dot. The
horizontal black lines indicate where the object may take one of several
different paths of action. Activity Diagrams are especially useful for objects
which contain a lot of complex logic that you wish to clearly present.
36
CreateCurriculu
m
SelectCourses
CreateCatalog
PlaceCatalogIn MailCatalog
Library
OpenRegistratio
n
CloseRegistratio
n
37
SEQUENCE DIAGRAMS
Interaction Diagrams show how groups of objects collaborate in some behavior.
Sequence Diagrams are the most common type of Interaction Diagram, and
show an instance of an object and the ‗life‘ of that object. In addition, the
interaction between objects is shown.
: student
CompleteForm
Submit
AddStudent
CheckAvailability
COLLABORATION DIAGRAMS
Collaboration Diagrams, like Sequence Diagrams, are also interaction
diagrams. Within the Collaboration Diagram, the objects are shown as icons.
The arrows as well as the numbers (in this case, 1 and 1.1) indicate the
order in which events occur. Collaboration Diagrams are good when you want
to get a quick overview of the general flow of events and object relations.
However, Sequence Diagrams are a better choice when you need to
demonstrate the timing and sequencing of events.
38
1: CompleteForm
2: Submit
: RegistrationForm
: student
3: AddStudent
4: CheckAvailability
: RegistrationManager : Course1
COMPONENT DIAGRAMS
Component Diagrams show the various components in a system and their
dependencies. The ‗component‘ represents a physical module of code. The
components are often the same as the packages, but they can be different,
since the components represent the physical packaging of code.
The ‗dependencies‘ between the components show how changes in one
component can affect the other components.
DEPLOYMENT DIAGRAMS
Deployment Diagrams show the physical relationship among software and
hardware components in the system. This diagram is a good place to show
how components and objects are routed and how they move around in a
distributed system. Deployment Diagrams really show how the Component
Diagrams interact. Many times, developers will combine the Component and
Deployment Diagrams into a single diagram.
PACKAGE DIAGRAMS
Package Diagrams simply show groups of classes and the dependencies that
exist between them. Package Diagrams are similar to Class Diagrams.
However, instead of showing the individual classes, they show the related
classes grouped together into a unit called a ―package.‖ A dependency exists
between two packages if any dependency exists between any two classes
inside each package. Package Diagrams can be really useful to obtain an
overview of a large system. Sometimes, developers also choose to display
the individual classes inside the packages.
39
THE RATIONAL UNIFIED PROCESS
The Rational Unified Process is a Software Engineering Process. It
provides a disciplined approach to assigning tasks and responsibilities within
a development organization. Its goal is to ensure the production of high-
quality software that meets the needs of its end-users, within a predictable
schedule and budget.
The Rational Unified Process has matured over many years and reflects the
collective experience of the many people and companies.
The Rational Unified Process activities create and maintain models. Rather
than focusing on the production of large amount of paper documents, the
Unified Process emphasizes the development and maintenance of models—
semantically rich representations of the software system under development.
The Rational Unified Process is a guide for how to effectively use the Unified
Modeling Language (UML). The UML is an industry-standard language that
allows us to clearly communicate requirements, architectures and designs.
The Rational Unified Process captures many of the best practices in modern
software development in a form that is suitable for a wide range of projects
and organizations. Deploying these best practices using the Rational Unified
Process as your guide offers development teams a number of key
advantages.
40
PHASES OF THE RATIONAL UNIFIED PROCESS
Inception phase
This phase brings to light an original vision of a potential product, and
transforms it into an actual project. Its purpose is to establish the business
case for a new product or a major update, and to specify the project scope.
For the development of a new product, the main outcome of this phase is a
―go-no go‖ decision to move into the next phase and to invest time and
money to analyze in detail what needs to be built, whether it can be built,
and how to build it.
For the evolution of an existing product, this may be a simple and short
phase, based on users‘ or customers‘ requests, on problem reports, on new
technological advances.
Entry criteria:
The expression of a need, which can take any of the following forms:
An original vision
A legacy system
A RFP (request for proposal)
The previous generation and a list of enhancements
Some assets (software, know-how, financial assets)
A conceptual prototype, or a mock-up
Exit criteria:
An initial business case containing at least:
A clear formulation of the product vision—the core requirements— in
terms of functionality, scope, performance, capacity, technology base
Success criteria (for instance revenue projection)
An initial risk assessment
An estimate of the resources required to complete the elaboration
phase.
Elaboration Phase
The purpose of this phase is to more thoroughly analyze the problem
domain, to define and stabilize the architecture and to address the highest
risk elements of the project.
So that at the end of the phase we can produce a comprehensive plan
showing how the 2 next phases will be done:
A baseline product vision (i.e., an initial set of requirements) based on
an analysis model
Evaluation criteria for at least the first construction iteration
A baseline software architecture
41
The resources necessary to develop and deploy the product, especially
in terms of people and tools
A schedule
A resolution of the risks sufficient to make a cost, schedule and quality
estimate of the construction phase.
Entry criteria:
The products and artifacts described in the exit criteria of the previous
phase.
The plan was approved by the project management, and funding
authority, and the resources required for the elaboration phase have
been allocated.
Exit criteria:
A detailed software development plan, containing:
An updated risk assessment
A management plan
A staffing plan
A phase plan showing the number and contents of the iteration
An iteration plan, detailing the next iteration
The development environment and other tools required
A test plan
A baseline vision, in the form of a set of evaluation criteria for the final
product
An objective, measurable evaluation criteria for assessing the results
of the initial iterations(s) of the construction phase
A domain analysis model (80% complete), sufficient to be able to call
the corresponding architecture ‗complete‘.
A software architecture description (stating constraints and limitations)
An executable architecture baseline.
42
Construction Phase
This phase is broken down into several iterations, fleshing out the
architecture baseline and evolving it in steps or increments towards the final
product. At each iteration, the various artifacts prepared during the
elaboration phase are expanded and revised, but they ultimately stabilize as
the system evolves in correctness and completeness.
New artifacts are produced during this phase beside the software itself:
documentation, both internal and for the end-users, test plans and test
cases, and deployment documents to support the next phase.
Exit criteria:
The same products and artifacts, updated, plus:
A release description document, which captures the results of an
iteration
Test cases and results of the tests conducted on the products,
An iteration plan, detailing the next iteration
Objective measurable evaluation criteria for assessing the results of
the next iteration(s).
Towards the end of the construction phase the following artifacts must be
produced, and are additional exit criteria for the last iteration of the phase:
A deployment plan, specifying as necessary:
Packaging
Pricing
Roll Out
Support
Training
Transition strategy (e.g., an upgrade plan from an existing system)
Production (e.g., making floppies and manuals)
User documentation
Transition Phase
The transition phase is the phase where the product is put in the hands of its
end users. From a technical perspective the iterations continue with one or
more releases, general availability releases, bug fix or enhancement
releases. The phase is completed when the user community is satisfied with
the product: formal acceptance for example in a contractual setting, or when
all activities on this product are terminated. It is the point where some of the
43
accumulated assets can be made reusable by the next cycle or by some
other projects.
Entry criteria:
The product and artifacts of the previous iteration, and in particular a
software product sufficiently mature to be put into the hands of its
users.
Exit criteria:
An update of some of the previous documents, as necessary, the plan
being replaced by a ―post-mortem‖ analysis of the performance of the
project relative to its original and revised success criteria;
A brief inventory of the organization‘s new assets as a result this cycle.
44
BEST PRACTICES OF THE RATIONAL UNIFIED PROCESS
Manage Requirements
The Rational Unified Process describes how to elicit, organize, and document
required functionality and constraints; track and document tradeoffs and
decisions; and easily capture and communicate business requirements. The
notions of use case and scenarios proscribed in the process has proven to be
an excellent way to capture functional requirements and to ensure that these
drive the design, implementation and testing of software, making it more
likely that the final system fulfills the end user needs. They provide coherent
and traceable threads through both the development and the delivered
system.
45
flexible, accommodates change, is intuitively understandable, and promotes
more effective software reuse. The Rational Unified Process supports
component-based software development.
Components are non-trivial modules, subsystems that fulfill a clear function.
The Rational Unified Process provides a systematic approach to defining an
architecture using new and existing components.
46
STRUCTURES OF THE RATIONAL UNIFIED PROCESS
The RUP process describes who is doing what, when and how in the form
of workers, artifacts, workflows and activities respectively.
Worker
A worker defines the behavior and responsibilities of an individual, or a group
of individuals working together as a team. The responsibilities assigned to a
worker include both to perform a certain set of activities as well as being
owner of a set of artifacts.
Activity
An activity of a specific worker is a unit of work that an individual in that role
may be asked to perform. The activity has a clear purpose, usually expressed
in terms of creating or updating some artifacts, such as a model, a class, a
plan. Every activity is assigned to a specific worker. The granularity of an
activity is generally a few hours to a few days, it usually involves one worker,
and affects one or only a small number of artifacts. An activity should be
usable as an element of planning and progress; if it is too small, it will be
neglected, and if it is too large, progress would have to be expressed in
terms of an activity‘s parts. Some examples of activities could be:
Plan an iteration, for the Worker: Project Manager
Find use cases and actors, for the Worker: System Analyst
Review the design, for the Worker: Design Reviewer
Execute performance test, for the Worker: Performance Tester
Artifact
An artifact is a piece of information that is produced, modified, or used by a
process. Artifacts are the tangible products of the project, the things the
project produces or uses while working towards the final product. Artifacts
are used as input by workers to perform an activity, and are the result or
output of such activities. In object-oriented design terms, as activities are
operations on an active object (the worker), artifacts are the parameters of
these activities.
Artifacts may take various shapes or forms:
A model, such as the Use-Case Model or the Design Model
A model element, i.e. an element within a model, such as a class, a
use case or a subsystem
A document, such as Business Case or Software Architecture
Document
Source code
Executables
Workflows
A mere enumeration of all workers, activities and artifacts does not quite
constitute a process. We need a way to describe meaningful sequences of
activities that produce some valuable result, and to show interactions
between workers.
47
A workflow is a sequence of activities that produces a result of observable
value. In UML terms, a workflow can be expressed as a sequence diagram, a
collaboration diagram, or an activity diagram.
There are nine core process workflows in the Rational Unified Process, which
represent a partitioning of all workers and activities into logical groupings.
The core process workflows are divided into six core ―engineering‖
workflows:
Business modeling workflow
Requirements workflow
Analysis & Design workflow
Implementation workflow
Test workflow
Deployment workflow
Business Modeling
One of the major problems with most business engineering efforts, is that
the software engineering and the business engineering community do not
communicate properly with each other. This leads to the output from
business engineering is not being used properly as input to the software
development effort, and vice-versa. The Rational Unified Process addresses
this by providing a common language and process for both communities, as
well as showing how to create and maintain direct tracability between
business and software models.
In Business Modeling the business processes are documented using so called
business use cases. This assures a common understanding among all
stakeholders of what business process needs to be supported in the
organization. The business use cases are analyzed to understand how the
business should support the business processes. This is documented in a
business object-model.
Requirements
The goal of the Requirements workflow is to describe what the system should
do and allows the developers and the customer to agree on that description.
To achieve this, the required functionality and constraints are organized and
documented. A Vision document is created, and stakeholder needs are
elicited. Actors are identified, representing the users, and any other system
that may interact with the system being developed.
48
Use cases are identified, representing the behavior of the system. Because
use cases are developed according to the actor's needs, the system is more
likely to be relevant to the users.
Each use case is described in detail. The use-case description shows how the
system interacts step by step with the actors and what the system does.
Non-functional requirements are described in Supplementary Specifications.
The use cases function as a unifying thread throughout the system's
development cycle. The same use-case model is used during requirements
capture, analysis & design, and test.
Analysis & Design results in a design model and optionally an analysis model.
The design model serves as an abstraction of the source code; that is, the
design model acts as a 'blueprint' of how the source code is structured and
written.
The design model consists of design classes structured into design packages
and design subsystems with well-defined interfaces, representing what will
become components in the implementation. It also contains descriptions of
how objects of these design classes collaborate to perform use cases.
Implementation
The purpose of implementation is:
To define the organization of the code, in terms of implementation
subsystems organized in layers.
To implement classes and objects in terms of components (source
files, binaries, executables, and others).
To test the developed components as units.
To integrate the results produced by individual implementers (or
teams), into an executable system. The system is realized through
implementation of components.
49
The Rational Unified Process describes how you reuse existing components,
or implement new components with well-defined responsibility, making the
system easier to maintain, and increasing the possibilities to reuse.
Components are structured into Implementation Subsystems. Subsystems
take the form of directories, with additional structural or management
information. For example, a subsystem can be created as a directory or a
folder in a file system, or a subsystem in Rational/Apex for C++ or Ada, or
packages using Java.
Test
The purposes of testing are:
To verify the interaction between objects.
To verify the proper integration of all components of the software.
To verify that all requirements have been correctly implemented.
To identify and ensure defects are addressed prior to the deployment
of the software.
The Rational Unified Process proposes an iterative approach, which means
that you test throughout the project. This allows you to find defects as early
as possible, which radically reduces the cost of fixing the defect. Tests are
carried out along three quality dimensions reliability, functionality,
application performance and system performance.
Strategies for when and how to automate test are described. Test
automation is especially important using an iterative approach, to allow
regression testing at then end of each iteration, as well as for each new
version of the product.
Deployment
The purpose of the deployment workflow is to successfully produce product
releases, and deliver the software to its end users. It covers a wide range of
activities including:
Producing external releases of the software.
Packaging the software.
Distributing the software.
Installing the software.
Providing help and assistance to users.
In many cases, this also includes activities such as:
Planning and conduct of beta tests.
Migration of existing software or data.
Formal acceptance.
Although deployment activities are mostly centered around the transition
phase, many of the activities need to be included in earlier phases to prepare
for deployment at the end of the construction phase. The Deployment and
Environment workflows of the Rational Unified Process contain less detail
than other workflows.
50
Project Management
Software Project Management is the art of balancing competing objectives,
managing risk, and overcoming constraints to deliver, successfully, a product
that meets the needs of both customers (the payers of bills) and the users.
The fact that so few projects are unarguably successful is comment enough
on the difficulty of the task.
This workflow focuses mainly on the specific aspect of an iterative
development process.
It is not a recipe for success, but it presents an approach to managing the
project that will markedly improve the odds of delivering successful software.
Environment
The purpose of the environment workflow is to provide the software
development organization with the software development environment—both
processes and tools—that are needed to support the development team.
This workflow focuses on the activities to configure the process in the context
of a project. It also focuses on activities to develop the guidelines needed to
support a project. A step-by-step procedure is provided describing how to
implement a process in an organization.
The environment workflow also contains a Development Kit providing you
with the guidelines, templates and tools necessary to customize the process.
51
PROCESS OVERVIEW OF THE RATIONAL UNIFIED PROCESS
52
THE TEN ESSENTIALS OF RATIONAL UNIFIED PROCESS
The following list describes the minimal set of items a project will have in
place if they are truly following the ―essence‖ of the Rational Unified Process:
1. Vision
2. Plan
3. Risks
4. Issues
5. Business Case
6. Architecture
7. Product
8. Evaluation
9. Change Requests
10.User Support
53
the success of the project. It identifies, in decreasing order of priority, the
events which could lead to a significant negative outcome.
Along with each risk, should be a plan for mitigating that risk. This serves as
a focal point for planning project activities, and is the basis around which
iterations are organized.
54
medium between the architect and other project team members regarding
architecturally significant decisions, which have been made on the project.
55
In RUP, the ―essence‖ of the Deployment workflow is to wrap up and deliver
the product, along with whatever materials are necessary to assist the end-
user in learning, using, operating and maintaining the product.
Some of Rational's tools that support the Rational Unified Process are listed
below.
Rational SoDA
Overview
56
Regenerates precise, up-to-date documents easily; preserves
additional data entered directly into the document.
Because it is a project-wide documentation automation tool, IBM
Rational SoDA is part of the supporting foundation -- the IBM
Rational® Team Unifying Platform -- in all IBM Rational Suite®
solutions
Rational ClearQuest
Overview
Rational ClearCase
Overview
57
o Linux
o Mainframe
58
Templates
4. PRODUCT FUNCTIONALITY................................................. 26
4.1. USE CASE1 ................................................................................. 26
4.1.1. Related Use Case / Shared Service..................................... 26
4.1.2. Preconditions / Prerequisites............................................. 26
4.1.3. Primary Scenario............................................................. 26
4.1.4. Secondary Scenario......................................................... 27
4.1.5. Post Conditions............................................................... 27
4.1.6. Special Requirements....................................................... 28
4.1.7. Use Case Diagram........................................................... 28
4.1.8. Screen Layout................................................................. 29
4.1.9. Data Field Definitions....................................................... 30
4.1.10. Business Rules .............................................................. 32
59
4.2.10. Business Rules .............................................................. 39
6. PERFORMANCE................................................................... 78
7. RISKS................................................................................. 78
8. OPEN ITEMS….................................................................... 79
9. APPROVALS ....................................................................... 80
60
Use Case Template
Table of Contents
1. Brief Description…………………………………………………..1
2. Actors………………………………………………………………….1
2.1 Primary Actors……………………………………………………………………….1
2.2 Secondary Actors…………………………………………………………………..2
3. Flow of Events………………………………………………………1
3.1 Basic Flow……………………………………………………………………………..1
3.2 Alternative Flows…………………………………………………………………..2
4. Special Requirements……………………………………………3
5. Pre-Conditions……………………………………………………..3
6. Post-Conditions …………………………………………………….3
61
Architecture Document
Table of Contents
1. BUSINESS OVERVIEW........................................................ 6
1.1. Business Background................................................................... 6
1.2. Scope........................................................................................ 6
1.3. Definitions, Acronyms, Abbreviations.............................................. 7
1.4. References.................................................................................. 9
1.5. Architecturally Significant Process and Use Cases............................. 9
1.5.1. Use Case1..................................................................... 10
1.5.2. Use Case2..................................................................... 11
1.5.3. Use Case3......................................................................12
1.6. Architecturally Significant Non Functional Requirements................... 14
1.6.1. Data Requirements......................................................... 14
1.6.2. Performance Requirements.............................................. 14
1.6.3. Integration Requirements................................................ 14
3. SYSTEM ARCHITECTURE..................................................... 24
3.1. Logical Architecture...................................................................... 24
3.1.1 Logical Component Architecture........................................ 24
3.1.2 Logical System Architecture............................................. 24
3.1.3 Data Flow...................................................................... 25
3.2. Physical Architecture..................................................................... 26
3.2.1 Physical Architecture Diagram........................................... 26
3.2.2 Hardware Requirements................................................... 26
3.2.3 Software........................................................................ 27
3.2.4 Network......................................................................... 27
3.2.5 Domain Information........................................................ 28
3.3. Design Elements.......................................................................... 28
3.3.1 Availability..................................................................... 28
3.3.2 Sizing............................................................................ 28
3.3.3 Scalability Options........................................................... 28
3.3.4 Failure Points.................................................................. 29
3.3.5 Backup and Recovery...................................................... 29
62
4. SUPPORT SERVICES........................................................... 30
4.1. Client and Web Services................................................................ 30
4.1.1 Application Access Request............................................... 30
4.1.2 User Setup Request......................................................... 30
4.1.3 Online Help / internal Requirements.................................. 30
4.2. System Support........................................................................... 31
4.2.1 Help Desk...................................................................... 31
4.2.2 Customer Service............................................................ 31
5. APPROVALS ....................................................................... 32
63
Technical Design Document
Table of Contents
1. INTRODUCTION....................................................................5
1.1 PROJECT OVERVIEW........................................................................5
1.2 SCOPE...........................................................................................5
1.3 REFERENCES..................................................................................5
4. DATA VIEW.........................................................................37
4.1 DATABASE TABLES........................................................................37
4.2 TABLE DEFINITIONS.......................................................................37
4.3 STORED PROCEDURE DEFINITIONS..................................................37
4.3.1 STORED PROCEDURE1.......................................................37
4.3.2 STORED PROCEDURE2.......................................................37
4.4 PERSISTENCE METHODOLOGY.........................................................38
5. DEPLOYMENT VIEW.............................................................39
5.1 INSTALLATION REQUIREMENTS .......................................................39
5.2 MAINTENANCE CONSIDERATIONS....................................................39
5.2.1 SECURITY........................................................................39
5.2.2 AUTHENTICATION.............................................................39
5.2.3 AUTHORIZATION (ACCESS CONTROL) ................................39
5.2.4 LOGGING.........................................................................39
6. IMPLEMENTATION VIEW.....................................................40
6.1 SERVERS.....................................................................................40
6.2 SOFTWARE...................................................................................40
6.3 NETWORK ....................................................................................40
6.4 IMPLEMENTATION DIAGRAM............................................................41
64
8. LEGACY CONNECTIONS ..................................................... 41
9. APPROVALS ...................................................................... 42
65
Test Plan Document
Table of Contents
1. INTRODUCTION....................................................................4
1.1 PURPOSE.......................................................................................4
1.2 SCOPE..........................................................................................4
1.3 REFERENCES..................................................................................4
2. TEST COVERAGE...................................................................4
2.1 SYSTEM FEATURES AND ASSOCIATED TEST CASES.............................4
2.2 TEST COVERAGE GOALS..................................................................5
2.3 TEST STRATEGIES..........................................................................5
2.4 COMPLETION CRITERIA...................................................................8
2.5 TEST DELIVERABLES.......................................................................8
2.6 RESOURCES REQUIRED...................................................................8
3. APPENDIX.............................................................................8
66
STRUCTURED QUERY LANGUAGE
What is SQL?
A database most often contains one or more tables. Each table is identified
by a name (e.g. "Customers" or "Orders"). Tables contain records (rows)
with data.
The table above contains three records (one for each person) and four
columns (LastName, FirstName, Address, and City).
SQL Queries
With SQL, we can query a database and have a result set returned.
A query like this:
LastName
AAA
CCC
EEE
67
SQL Data Manipulation Language (DML)
SQL (Structured Query Language) is a syntax for executing queries. But the
SQL language also includes a syntax to update, insert, and delete records.
These query and update commands together form the Data Manipulation
Language (DML) part of SQL:
The Data Definition Language (DDL) part of SQL permits database tables to
be created or deleted. We can also define indexes (keys), specify links
between tables, and impose constraints between database tables.
Syntax
SELECT column_name(s) FROM table_name
68
To select all columns from the "Persons" table, use a * symbol instead of
column names, like this:
SELECT * FROM Persons
Syntax
SELECT DISTINCT column_name(s) FROM table_name
Syntax
SELECT column FROM table WHERE column operator value
69
Using the WHERE Clause
To select only the persons living in the city "New York", we add a WHERE
clause to the SELECT statement:
Using Quotes
SQL uses single quotes around text values (most database systems will also
accept double quotes). Numeric values should not be enclosed in quotes.
Syntax
SELECT column FROM table WHERE column LIKE pattern
Using LIKE
The following SQL statement will return persons with first names that start
with an 'A':
The following SQL statement will return persons with first names that end
with an 'A':
Syntax
INSERT INTO table_name VALUES (value1, value2,....)
You can also specify the columns for which you want to insert data:
70
INSERT INTO table_name (column1, column2,...)
VALUES (value1, value2,....)
Syntax
UPDATE table_name
SET column_name = new_value
WHERE column_name = some_value
Syntax
DELETE FROM table_name
WHERE column_name = some_value
AND & OR
AND and OR join two or more conditions in a WHERE clause.
The AND operator displays a row if ALL conditions listed are true. The OR
operator displays a row if ANY of the conditions listed are true.
71
Syntax
Use AND to display each person with the first name equal to "AAA", and the
last name equal to "BBB":
SELECT * FROM Persons
WHERE FirstName='AAA'
AND LastName='BBB'
Syntax
Use OR to display each person with the first name equal to "AAA", or the last
name equal to "BBB":
SELECT * FROM Persons
WHERE firstname='AAA'
OR lastname='BBB'
IN
The IN operator may be used if you know the exact value you want to return
for at least one of the columns.
ALIASES
With SQL, aliases can be used for column names and table names.
Column Name Alias
The syntax is:
72
SELECT column FROM table AS table_alias
Joins
Sometimes we have to select data from two or more tables to make our
result complete. We have to perform a join.
Tables in a database can be related to each other with keys. A primary key is
a column with a unique value for each row. The purpose is to bind data
together, across tables, without repeating all of the data in every table.
Employees:
Employee_ID Name
01 AAA, BBB
02 CCC, DDD
03 EEE, FFF
04 GGG, HHH
Orders:
Prod_ID Product Employee_ID
111 Printer 01
112 Monitor 03
113 Mouse 03
114 Keyboard 04
73
WHERE Employees.Employee_ID=Orders.Employee_ID
Example
Who ordered a keyboard?
SELECT Employees.Name
FROM Employees, Orders
WHERE Employees.Employee_ID=Orders.Employee_ID
AND Orders.Product='Keyboard'
Types of Functions
There are several basic types and categories of functions in SQL. The basic
types of functions are:
Aggregate Functions
Scalar functions
Aggregate functions
Aggregate functions operate against a collection of values, but return a single
value. When used among many other expressions in the item list of a SELECT
statement, the SELECT must have a GROUP BY clause.
74
Scalar functions
Scalar functions operate against a single value, and return a single value
based on the input value. Scalar functions differ from database to database.
GROUP BY...
GROUP BY... was added to SQL because aggregate functions (like SUM)
return the aggregate of all column values every time they are called, and
without the GROUP BY function it was impossible to find the sum for each
individual group of column values.
HAVING...
HAVING... was added to SQL because the WHERE keyword could not be used
against aggregate functions (like SUM), and without HAVING... it would be
impossible to test for result conditions.
75