Академический Документы
Профессиональный Документы
Культура Документы
searchStr=elicitation
%20requirements
Elicitation Techniques
After securing the proper stakeholders, an analyst must determine the best
techniques for eliciting requirements. Commonly used requirements elicitation
methods (as identified by BABOK) include:
Conduct Elicitation
An analysts projects business needs and the stakeholder mix will determine
which of the above elicitation method(s) are best. Elicitation does not normally
occur solely prior to requirements however; it occurs throughout a project
during discovery, modeling, and even testing. Whenever elicitation takes place
during a projects life cycle, the same principles apply to make it successfulthe
correct mix of stakeholders, a thorough understanding of the business need,
properly selected elicitation techniques, and meticulous attention to detail.
Once the elicitation methods have been employed, an analyst must document
the elicitation quickly, while it is still fresh in her mind, and share the results with
appropriate stakeholders to confirm their agreement with the findings. This stage
is essential to ensure that the analyst has accurately grasped, and stakeholders
have accurately communicated, the projects needs.
INTERVIEWS
Interviews, either with an individual or with a group of people, offer the opportunity for
rich, detailed communication.
PREPARE
Define interview goal: Determine exactly why you are holding the interview
and what you want to achieve in it.
Determine logistics: When and where will the interview be held, and how will
the interviewees be invited?
Design the interview: Decide on the format that is most appropriate for the
interviewees and the goal. Should it be structured with a detailed agenda and formal
set of questions, or unstructured with a looser agenda, depending more on ad hoc
interaction? Should the questions be open-ended requiring sentences or paragraphs
to answer, or closed-ended requiring short, even one-word answers?
CONDUCT THE INTERVIEW
Take time at the beginning to ensure that the interviewee(s) knows the purpose of
the interview, who you are, and what your role is. Wrap up the interview with
questions like "Is there anything else you would like to add?" and a hearty "Thank
you!"
FOLLOW UP
Like any other meeting, interview minutes should be published. This allows the
interviewees to see what you learned in the interview and validate that what you
heard is what they intended to say.
WORKSHOPS
A workshop is a structured method for interacting with a group of people. Workshops
can generate much information quickly if well facilitated and if participants are active.
PREPARE FOR WORKSHOP
Define purpose: Determine exactly why you are holding the workshop and
what you want to achieve in it.
Determine logistics: When and where will the workshop be held, and how
will the participants be invited?
FOCUS GROUPS
A focus group is an interactive session with a carefully selected group of people
designed to capitalize on the synergy of a group.
PREPARE FOR THE FOCUS GROUP
Define roles, topics, and logistics: Define who (among the people running
the focus group) must do what, and the specific topics that the participants will
discuss. Also define the basic logistics such as when and where the focus group will
be held, and how the participants will be invited.
RUN THE FOCUS GROUP
Carefully facilitate the group to ensure free and open interaction among the
participants. Participants must feel free to interact openly or the focus group could
fail.
FOLLOW UP
The focus group report records what was learned, including both agreements and
disagreements among the participants.
BRAINSTORMING
Brainstorming is a method of quickly generating many creative ideas from a group of
people.
PREPARE FOR BRAINSTORMING
Define topics and time limits: Define precisely what will be the focus of the
brainstorming session, and how long it will be allowed to go on.
Determine evaluation criteria: Decide how the ideas that come out of the
brainstorming session will be judged afterward. Be sure that the evaluation does not
go on during the brainstorming session.
CONDUCT BRAINSTORMING
Encourage a free flow of ideas. This requires careful facilitation to ensure that
participants feel comfortable with adding any idea to the list, and that no criticism or
even discussion of the ideas goes on during the brainstorming session.
FOLLOW UP
Apply the evaluation criteria to the ideas that were generated to reduce the list to only
those ideas that are reasonable or viable.
OBSERVATION
Observation is watching people as they go about their jobs. Observation can be an
effective way to gain a realistic and detailed understanding of how work is done in the
production environment; however, it is time consuming and may disrupt work.
PREPARE FOR OBSERVATION
Define goals and individuals to be observed: Decide what you are trying to
accomplish in the observation and who you should observe in order to achieve those
goals
workers. "Invisible" refers to the fact that the workers are not even aware that
observation is taking place.
Active/visible: Interacting with those who are being observed. For
example, asking questions and having them describe what they are doing and why.
OBSERVE
If people believe that they are being evaluated, they are likely to do the work "by the
book," instead of the way they normally do it. So those who are being observed must
be assured that the observation is not for the purpose of judging them. As the
observation goes on, keep detailed records of what is observed and questions that
must be answered later.
FOLLOW UP
After obtaining answers to any remaining questions, publish the results of the
observation.
SURVEYS/QUESTIONNAIRES
Surveys allow you to collect information from many people in a relatively short
period. A survey can be an effective way to collect quantitative information; however,
writing the questions requires great skill and care to avoid ambiguity that could
compromise the utility of the results.
PREPARE FOR THE SURVEY
Define purpose, target people, and logistics: Decide what you are trying to
learn from the survey, who you should target in order to achieve those goals, and
how the survey should be distributed (for example, paper, e-mail, internet,
telephone).
Define target response level and follow-up activities: Getting many people
to respond to a survey is difficult. If you are expecting more than a small minority of
the target people to respond, it will require follow-up work beyond merely distributing
the survey.
Enough/Little:
Nothing at all:
Current Account:
NRI:
Infrequent:
Not at all:
Telephone Banking:
ATM Services:
No:
Not Sure:
Business Transactions:
Both:
7. Of our Internet Banking features which would you use most? Make as many
selections as you wish.:
Inter Account Funds Transfer:
Savings/DDA/Term Deposits/Loans:
No:
Regularly:
Balance on
Infrequently:
Not at all:
No:
Not at
all:
Regularly:
Infrequently:
Not at all:
12. Have you had difficulty logging onto the bank's website?:
All the time:
Regularly:
Infrequently:
Not at all:
No:
No:
OK
C) No response.
C) No response.
7. What is the
Fixed Deposits
NRI Account.
Transaction Management:
The transaction made through either net or manually in bank need to have a
consistency with respect to the account details and other related information like
transaction details across various databases.
Value Added Service
The solution provides good number of value added services in comparison to the
normal banking services. Account holder can view his accounts and give the
instructions of making payment to various government organizations for various
services. An account holder can issue the instructions to transfer certain amount
to any particular account number of the same / different bank. Individual can log
on to the site and open new bank account in his name online by following the
simplified registration form instructions
Security
The Net Banking system deals with a lot of proprietary information for its users,
which are confidential. It is therefore imperative to provide a means though which
information can be kept confidential. This is also ensures that the data that is put
into the system maintains its integrity because malicious or unauthorized
individual will not have access to alter them. The security is at two different
levels, one at account holder and other at administrative level at the banks
office.
Savings Account
Input
Customer Details.
Output
Alert message.
Current Account
Input
Customer Details.
Output
Alert message.
Credit Card
Customer needs to open a savings/current account bank account before opening
the credit card account. Credit card account will be linked with their
savings/current account. Customer needs to give their account detail when
applying for the credit card.
Input
Customer account details
Output
Alert message
Term Deposit
Term Deposit can be of two types: Flexible deposit and Cumulative deposit.
Flexible Deposit
Flexible deposit has links with the savings bank account.
Input
Customer details
Amount
Period
o Years
o Months
o Days
Renewal Option
o Repay the deposit
o Auto Renewal
Principal only
Cumulative Deposit
Input
Customer details
Amount
Period
o Years
o Months
o Days
Output
Alert message
Recurring Deposit
Input
Customer details
Period
Installment amount
Output
Alert message
2) Teller Services
Customer can use the facility of Teller to receive the details of their account. Teller
services component provides the following services:
Account Summary
Transaction Details
Card Transaction
Interest Statement
Un Cleared Cheque
Account Summary
Customer can go to the Teller option and select the Account Summary. It provides
account summary of the customer. Account summary will be grouped as:
Regular Accounts
Investment Accounts
Loan Accounts
Credit card Account
On selecting the account summary field, the type of accounts field will be
displayed. Here the customer selects their account type and the account number
will be entered further. On entering these, the account summary is displayed.
Further, customer can enter from and to dates to see the opening balance and the
closing balance.
Input
Account Type
Account Number
Statement Duration
Output
Date
Description
Credit/Debit
Amount
Balance
3) Transaction Details
User can use the transaction details option to obtain the details of their particular
transactions.
Input
Account type
Account number
Period of transaction
Output
Transaction history for the specified period
Card Transaction
The card transaction option will be provided for displaying the card transaction
details.
Input
Card Type
Card Number
Period of transaction
Output
Card Number
Account Number
Expiry Date
Date of transaction
Pay To
Amount
4) Interest Statement
In this option, a customer receives statement on interest earned/debited in their
account for a particular period
Input
Account Type
Account Number
Interest type (accrued/credited/debited)
From and to dates
Output
Date
Description (loan no. or flexi deposit no etc)
Interest Accrued/Credited/Debited
Interest credited during last year
Interest credited during the current year
5) Un Cleared Cheque
Here, a customer gets report about the Un Cleared Cheque. A separate table is
being maintained for tracking cheque clearance.
Input
Account type
Account number
Output
Details of Un-Cleared Cheque:
Date
Drawn on
Cheque number
Amount
6) Transaction Services
This module offers two types of services:
Funds Transfer
Tax Payment
Funds Transfer
Customers can use this service for regular payment from one account to another.
Input
Tax Payment
The Tax Payment component facilitates the customer to calculate tax payment
amount and remit the same to the tax collecting authority.
Options provided to the customer include:
Alert message.
7) Bill Payment Services
Bill Payment Service components facilitate customers to instruct the banks to
issue payment to their bills regularly against utilities such as electricity, gas,
water etc. Customer nominates the service provider to the bank, provided the
bank has a tie up with the provider. Service providers publish the bills to the bank
and the customers will be alerted subsequently. Bank will make payment to these
service providers as they get on line instructions from the customer. Bank debits
service charge from customers account for providing the service.
Following details will be displayed and the customer has multiple options to
choose:
Bill No.
Bill date
Bill period
Payee
Amount
Description
Select for payment (check box)
Customer has to select bills to be paid from the check box option. The customer
also gives the account number in which the amount has to be debited.
Output
Alert message will be displayed to the user showing the service charge amount
that will be debited from his account.
8) Other Payments
Other Payments component incorporates the following services:
Recurring Payments
Remittances
Recurring Payments
A customer can move the regular payment facility from one account to another.
Bank determines the service charge for providing the service to the user. It will be
displayed to the user for information to decide for utilizing the services provided
by the bank.
Here, the Customer instructs the bank to remit their recurring payment.
Input
User has to enter the following fields:
Payee Name
Payment frequency
Start date
End date
Payment Amount
Account Type
Account No.
Branch
Output
Alert message showing the service charge for providing the service.
Remittances
Following services are provided to the customer:
Input
The customer provides following details:
Payee name
Cheque Reorder
New Card Request
Draft / Cashiers Cheque
Stop Payment
Cheque Reorder
In this case, the customer requests bank to issue a new chequebook and the bank
may charge the customer for it.
Input
Account Type
Account No.
Output
Alert message showing the service charge to be debited from the customers
account.
Input
Card No.
Card Type
Lost on Date
Output
Alert message showing the service charge to be debited from the customers
account.
Input
Options to user:
Draft
Cashiers cheque
Further, customer enters the following details:
Payee name
Drawn on
Amount
Delivery options
o Deliver at customers doorstep
o Deliver at payees doorstep
Payees address
o Door No.
o Street
o Area
o City
o PIN
Output
Alert message showing the service charge to be debited from the customers
account.
Stop Payment
In this process, the customer informs the bank to hold payment for the cheques
he has issued.
Input
Account Number
Branch
Cheque No
Output
On entering the cheque number, following will be displayed:
Payee Name
Date of issue
Branch
Alert message also will be displayed to the customer with service charge.
10) Maintenance Services
Maintenance Services module comprises the following components:
Customer ID
Customer details
Output
Alert message showing the new account number.
Close Account
In this process, an existing account holder closes his account.
Input
Account type
Account number
Branch
Reason
For remittance of balance
o Account Transfer
Account number
Bank name
Branch
o Cashiers cheque details
Output
Account summary will be presented to the customer. Check list will be provided to
the customer regarding pending standing instructions, pending Cheque etc.
Input
Customer has to enter the following information:
Account type
Account number
Branch
Mode of operation
Account link
Threshold
Output
Alert message displaying that the account details have been modified.
Input
Account type
Account number
Branch
Applicant number
Customer details
Output
Alert message showing that the customers details have been modified.
11) User Alerts
The User Alerts module consists of the following processes:
where in the world. No need to travel to pay the bills. For doing this process
electronically have to spend some time.
Operational Feasibility:
In our application front end is developed using GUI. So it is very easy to the
customer to enter the necessary information. But customer has some knowledge
on using web applications before going to use our application.
one can start with the required outputs and work backwards evolving so called
front-back design. We have applied both the top down and bottom up approach in
our design approach.
DATABASE DESIGN
Databases are normally implemented by using a package called a Data Base
Management System (DBMS). Each particular DBMS has somewhat unique
characteristics, and so such, general techniques for the design of database are
limited. One of the most useful methods of analyzing the data required by the
system for the data dictionary has developed from research into relational
database, particularly the work of E.F.Codd. this method of analyzing data is called
Normalization. Unnormalized data are converted into normalized data by three
stages. Each stage has a procedure to follow.
NORMALIZATION
The first stage is normalization is to reduce the data to its first normal form, by
removing repeating items showing them as separate records but including in
them the key fields of the original record.
The next stage of reduction to the second normal form is to check that the record,
which one is first normal form, all the items in each record are entirely dependent
on the key of the record. If a data item is not dependent on the key of the record,
but on the other data item, then it is removed with its key to form another record.
This is done until each record contains data items, which are entirely dependent
on the key of their record.
The final stage of the analysis, the reduction of third normal form involves
examining each record, which one is in second normal form to see whether any
items are mutually dependent. If there are any item there are removed to a
separate record leaving one of the items behind in the original record and using
that as the key in the newly created record.
BUSINESS MODELING:
The information flow among business function is modeled in a way that answers
the following questions: what information drives the business process? What
information is generated? What generate it? Where does the information go? Who
process it?
DATA MODELING:
The information flow defined as a process of the business modeling is refined into
a set of data objects that are needed to support the business. The characteristics
(called attributes) of each object are identified and relationships between these
objects are defined.
PROCESS MODELING:
The data objects defined in the data-modeling phase are transformed to achieve
the information flow necessary to implement a business function. Processing
description are created for addition, modifying, deleting, or retrieving a data
object.
THE LINEAR SEQUENTIAL MODEL:
The linear sequential model for software engineering some times called the
classic model or the water fall model, the linear sequential suggests a
systematic, sequential approach to software development that begins at eth
system level and process through analysis, design, coding, testing, and
maintenance.
The linear sequential model is the oldest and the most widely used paradigm for
software engineering. Modeled after the conventional engineering cycle, the linear
sequential model encompasses the following activities:
1) SYSTEM/INFORMATION ENGINEERING AND MODELLING:
Because software is always part of a larger system (or business), work begins
by establishing requirements for all system elements and then allocating some
subset of these requirements to software. This system view is essential when
software must interface with other elements such as hardware, people, and
databases.
System engineering and analysis encompasses requirements gathering at the
system level with a small amount of top-level analysis and design. Information
engineering encompasses requirements gathering at the strategic business level
and at the strategic business level and at the business area level.
2) SOFTWARE REQUIREMENTS ANALYSIS:
The requirements gathering process is intensified and focused specifically on
software. To understand the nature of the programs to be built, the software
Engineer must under stand the information domain for the software, as well as
required function, behavior, performance, and inter facing. Requirements for the
both the system and the software are documented and reviewed with the
customer.
3) DESIGN:
Software design is actually a multi step process that focuses on four distinct
attributes of a program: data structure, software architecture, interface
representations, and procedural detail. The design process translates
requirements into a representation of the software that can be assessed for
quality before code generation begins. Like requirements the design is
documented and becomes part of the software configuration.
4) CODE GENERATION:
The design must be translated into a machine-readable form. The code
generation step performs this task. If design is performed in a detailed manner,
code generation can be accomplished mechanistically.
5) TESTING:
Once code has been generated, program testing process focuses on the logical
internals of the software, assuring that all statements have been tested, and on
the functional externals that is, conducting tests to uncover errors and ensure that
defined input will produce actual results that agree with required results.
6) MAINTENANCE:
Software will undoubtedly undergo change after it is delivered to the customer.
Change will occur because errors have been encountered, because the software
must be adapted to accommodate changes in its external environment (e.g., a
change required because of a new operating system or peripheral devices), or
because the customer requires functional or performance enhancement. Software
maintenance reapplies each of the preceding phases to an existing program
rather than a new one
INTERNET TERMINOLOGY
Java and Internet:
The Internet helped catapult Java to the forefront of programming and Java in turn
has had a profound effect on the Internet. The reason is simple: Java expands the
universe of objects that can move about freely in cyberspace. In a network, there
are two broad categories of objects transmitted between the Server and your
Personal Computer: passive information and dynamic, active programs like an
object that can be transmitted to your computer, which is a dynamic, selfexecuting program. Such a program would be an active agent ton the client
computer, yet the server would initiate it. As desirable as dynamic, networked
programs are, they also present serious problems in the areas of security and
portability. Prior to Java cyberspace was effectively closed to half the entities that
now live there. Java addresses these concerns and doing so, has opened the door
to an exiting a new form of program.
The rise of server-side Java applications is one of the latest and most exciting
trends in Java programming. It was first hyped as a language for developing
elaborate client-side web content in the form of applets. Now, Java is coming into
its own as a language ideally suited for server-side development. Businesses in
particular have been quick to recognize Javas potential on the server-Java is
inherently suited for large client/server applications. The cross platform nature of
Java is extremely useful for organizations that have a heterogeneous collection of
servers running various flavors of the Unix of Windows operating systems. Javas
modern, object-oriented, memory-protected design allows developers to cut
development cycles and increase reliability. In addition, Javas built-in support for
networking and enterprise API provides access to legacy data, easing the
transition from older client/server systems.
Java Servlets are a key component of server-side java development. A Servlets is
a small, plug gable extension to a server that enhances the servers functionality.
Servlets allow developers to extend and customize and Java enabled server a web
server, a mail server, an application server, or any custom server with a hitherto
unknown degree of portability, flexibility and ease.
JAVA SERVER PAGE (JSP)
Java Server Pages is a simple, yet powerful technology for creating and
maintaining dynamic-content web pages. Based on the Java programming
language, Java Server Pages offers proven portability, open standards, and a
mature re-usable component model.
PORTABILITY
Java Server Pages files can be run on any web server or web-enabled application
server that provides support for them. Dubbed the JSP engine, this support
involves recognition, translation and management of the Java Server Pages
lifecycle and its interaction with associated components.
The JSP engine for a particular server might be built-in or might be provided
through a 3rd party add-on. As long as the server on which you plan to execute
the Java Server Pages supports the same specification level as that to which the
file was written, no change should be necessary as you move your files from
server to server. Note, however, that instructions for the setup and configuration
of the files may differ between files.
COMPOSITION
It was mentioned earlier that the Java Server Pages architecture could include
reusable Java components. The architecture also allows for the embedding of a
scripting language directly into the Java Server Pages file. The components
current supported include Java Beans and Serves. As the default scripting
language, Java Server Pages use the Java Programming language. This means that
scripting on the server side can take advantage of the full set of capabilities that
the Java programming language offers.
PROCESSING
A Java Server Pages file is essentially an HTML document with JSP scripting or
tags. It may have associated components in the form of. class, .jar, or .ser files-or it may not. The use of components is not required.
The Java Server Pages file has a .jsp extension to identify it to the server as a Java
Server Pages file. Before the page is served, the Java Server Pages syntax is
parsed and processed into a servlet on the server side. The servlet that is
generated, outputs real content in straight HTML for responding to the customer.
Because it is standard HTML, the dynamically generated response looks no
different to the customer browser than a static response.
ACCESS MODELS
A Java Server Pages file may be accessed in at least two different ways: A client
request comes directly into a Java Server Page.
In this scenario, suppose the page accessed reusable Java Bean components that
perform particular well-defined computations like accessing a database. The result
of the Beans computations, called result sets is stored within the Bean as
properties. The page uses such Beans to generate dynamic content and present it
back to the client. A request comes through a servlet.
The servlet generates the dynamic content. To handle the response to the client,
the servlet creates a Bean and stores the dynamic content (sometimes called the
result set) in the Bean. The servlet then invokes a Java Server Page that will
present the content along with the Bean containing the generated from the
servlet.
There are two APIs to support this model of request processing using Java Server
Pages. One API facilitates passing context between the invoking servlet and the
Java Server Page. The other API lets the invoking servlet specify which Java Server
Page to use.
In both of the above cases, the page could also contain any valid Java code. The
Java Server Pages architecture separation of content from presentation- -it does
not mandate it.
JDBC requires that the SQL statements be passed as Strings to Java methods. For
example, our application might present a menu of database tasks from which to
choose. After a task is selected, the application presents prompts and blanks for
filling information needed to carry out the selected task. With the requested input
typed in, the application then automatically invokes the necessary commands.
In this project we have implemented three-tier model, commands are sent to a
middle tier of services, which then send SQL statements to the database. The
database process the SQL statements and sends the results back to the middle
tier, which then sends them to the user. JDBC is important to allow database
access from a Java middle tier.
What Is JDBCTM?
JDBCTM is a JavaTM API for executing SQL statements. (As a point of interest, JDBC
is a trademarked name and is not an acronym; nevertheless, JDBC is often
thought of as standing for "Java Database Connectivity".) It consists of a set of
classes and interfaces written in the Java programming language. JDBC provides a
standard API for tool/database developers and makes it possible to write database
applications using a pure Java API.
Using JDBC, it is easy to send SQL statements to virtually any relational database.
In other words, with the JDBC API, it isn't necessary to write one program to
access a Sybase database, another program to access an Oracle database,
another program to access an Informix database, and so on. One can write a
single program using the JDBC API, and the program will be able to send SQL
statements to the appropriate database. And, with an application written in the
Java programming language, one also doesn't have to worry about writing
different applications to run on different platforms. The combination of Java and
JDBC lets a programmer write it once and run it anywhere.
Java being robust, secure, easy to use, easy to understand, and automatically
downloadable on a network, is an excellent language basis for database
applications. What is needed is a way for Java applications to talk to a variety of
different databases. JDBC is the mechanism for doing this.
JDBC extends what can be done in Java. For example, with Java and the JDBC API,
it is possible to publish a web page containing an applet that uses information
obtained from a remote database. Or an enterprise can use JDBC to connect all its
employees (even if they are using a conglomeration of Windows, Macintosh, and
UNIX machines) to one or more internal databases via an intranet. With more and
more programmers using the Java programming language, the need for easy
database access from Java is continuing to grow.
MIS managers like the combination of Java and JDBC because it makes
disseminating information easy and economical. Businesses can continue to use
their installed databases and access information easily even if it is stored on
different database management systems. Development time for new applications
is short. Installation and version control are greatly simplified. A programmer can
write an application or an update once, put it on the server, and everybody has
access to the latest version. And for businesses selling information services, Java
and JDBC offer a better way of getting out information updates to external
customers.
CONNECTION
A connection object represents a connection with a database. A connection
session includes the SQL statements that are executed and the results that are
returned over the connection. A single application can have one or more
connections with a single database, or it can have connections with many
different databases.
OPENING A CONNECTION
The standard way to establish a connection with a database is to call the method
DriverManager.getConnection. This method takes a string containing a URL. The
Driver Manager class, referred to a the JDBC management layer, attempts to
locate a driver than can connect to the database represented Driver classes, and
when the method get Connection is called, it checks with each driver in the list
until it finds one that can connect uses this URL to actually establish the
connection.
-usually the driver or the database connectivity mechanism, which may be supported by one or more drivers. A prominent
example of a sub protocol name is oracle, which has been reserved for URLs that specify thin-style data source names.
- a way to identify the database. The sub names can vary, depending on the sub protocol, and it can have a sub name with any
internal syntax the driver writer chooses. The point of a sub name is to give enough information to locate the database.
SENDING STATEMENT:
Once a connection is established, it is used to pass SQL statements to its underlying database. JDBC does not put any restrictions
on the kinds of SQL statements that can be sent; this provides a great deal of flexibility, allowing the use of database-specific
statements or even non-SQL statements. It requires, however, that the user be responsible for making sure that the underlying
database can process the SQL statements being sent and suffer the consequences if it cannot.
DRIVER MANAGER:
The Driver Manager class is the management layer of JDBC, working between the user and the drivers. It keeps track of the
drivers that are available and handles establishing a connection between a database and the appropriate driver. It addition, the
driver manager class attends to things like driver login time limits and the printing of log and tracing messages. The only method
in this class that a general programmer needs to use directly is DriverManager.getConnection. As its name implies, this method
establishes a connection to a database.
ORACLE 8i
Introduction to Oracle:
Any programing environment used to create containers, to manage human data, in the conceptualization as a Data Management
System. Traditionally, the block of human data being managed is called a Database. Hence, in very simple terms, these
programming environments can the conceptualized as Database Management Systems, in short DBM systems.
All Databases Management Systems (that is, Oracle is DBMS) allow users to create containers for data stories and management.
These containers are called cells. The minimum information that has to be given to Oracle for a suitable container to be
constructed, which can hold free from human data, is
The cell name
The cell length
Another name that programming environments use for a Cell is Field. These can the conceptualized as follows.
Basic Database Concepts:
A database is a corporate collection of data with some inherent meaning, designed, built and populated with data for a specific
purpose. A database stores data that is useful to us. This data is only a part of the entire data available in the world around us.
To be able to successfully design and maintain databases we have to do the following:
Identify which part of the worlds data is of interest to us.
Identify what specific objects in that part of the worlds data are of interest to us.
Identify a relationship between the objects.
Hence the objects, their attributes and the relationship between them that are of interest to us are still owed in the database that
is designed, built and populated with data for a specific purpose.
Characteristics of a Database Management System:
Information Representation:
All information stored in a relational database is represented only by data item values, which are stored in the tables that make
up the database. Associations between data items are not logically represented in any other way, such as the use of pointers
from one table to the other.
Logical accessibility:
Every data item value stored in relational database is accessible by stating the nature of the table it is stored in, the name of the
column under which it is stored and the value of the primary key that defines the row in which it is stored.
Representation of null values:
The database management system has a consistent method for representing null values. For example, null values for numeric
data must be distinct from zero or any other numeric and for the character data it must be different from a string of blanks or any
other character value.
Catalogue facilities:
The logical description of the relation database is represented in the same manner as ordinary data. This is done so that the
facilities of the relation database management system itself can be used to maintain database description.
Data Language:
The relational database management system may support many types of languages for describing data and accessing the
database. However, there must be at least one language that uses ordinary character strings to support the definition of data,
the definition of views, the manipulation of data, constraints on data integrity, information concerning authorization and the
boundaries for recovery of units.
View Updatability:
Any view that can be defined using combination of basic tables, that are theoretically updateable, these capital of being updated
by the relational database management system.
Insert, Update and Delete:
Any operand that describes the results of a single retrieval operation is capable of being applied to an insert update or delete
operation as well.
Physical data independence:
Changes made to physical storage representation or access methods do not require changes to be made to application
programmers.
Logical Data Independence:
Changes made to tables, that do not modify any data stored in that table, do not require changes to be made to application
programmers.
Integrity Constraints:
Constraints that apply to entity integrity and referential integrity are specifiable by the data language implemented by the
database management system and not by the statements coded into the application program.
Database Distribution:
The data language implemented by the relation database management system supports the ability to distribute the database
without requiring changes to be made to application programmers. This facility must be provided in the data language, whether
or not the database management system itself supports distributed databases.
Non- Subversion:
If the relational database management system supports facilities that allow application programmers to operate on the tables a
row at a time, an application programmer using this type access is prevented from by passing entity integrity or referential
integrity constraints that are defined for the database.
RD Recurring Deposit
14) LOANS Table contains details of Loans availed by different Account Holders.
15) CHEQUES Table contains details of Cheques submitted by the Account Holders.
20) DRAFT_CHEQUE Table contains the details of Drafts and Cheques Issued.
Requirements while every project needs absolutely clear goals and objectives, the
detailed requirements which need to be implemented to achieve those goals are probably
not well understood in advance, and are likely to change over the life of the project
Understanding of the problem domain while accept that our understanding cannot
be complete and that the initial vision of the solution needs to be able to change as we learn
Adaptive projects require an adaptive approach to development that allows the product to evolve
as our understanding unfolds over the life of the project. The Iterative and Incremental way of
working on Agile projects provides the needed feedback mechanism[2] to deliver adaptive
projects.
Despite the adaptive nature of the Agile project ecosystem, it is reasonable and realistic that
management want to know how much will this cost and how long will it take. Organizational
resources need to be allocated to the project and decisions need to be made about what work to
undertake. This means we need to provide feedback at a number of levels to answer the initial
set of questions and on an ongoing basis through the project to ensure we are still delivering the
best value for our organization's investment.
To achieve this we need to plan at many levels.
There are two broad categories which planning happens in:
1.
The highest level of planning happens almost completely outside the team and this has
to do with selecting which initiatives should be funded doing the right work.
2.
Once a project has passed the should we do this? filter we need to focus on doing the
work right. This is where the five levels of planning on a project come in.
After an idea has been raised there needs to be an initial high-level filter is this worth
considering any further. Frequently this is based on a very quick cost-benefit analysis and
feasibility assessment of the idea. Some ideas will automatically pass the first filter (a project that
is about compliance with a legislation change must be done, for instance), some are quickly
discarded (cost prohibitive or completely out of alignment with the organisations strategic
objectives) and some will be worth considering further.
Those that get automatic approval and those which are worth considering further should feed
into a Portfolio Planning process.
Portfolio Planning
Portfolio planning is a governance level activity which is about selecting the suite of programs
and projects which the organisation should fund at any given time. Inevitably there will be more
work requested than can be funded and the portfolio management process selects those which
will be funded.
Deciding which work to undertake should be based on the organisations mission and goals
work should only be funded that delivers on the strategy set at the highest levels in the
organisation. Portfolio planning is a risk-return based activity the organisations risk
management strategy helps select which pieces of work to fund.
Portfolio planning should happen above the level of any functional group in the business to
ensure the end-to-end impact and value of the selected work is considered. At this level projects
will impact many functional areas and it is important to avoid turf wars over jurisdiction. It is
likely that any significant piece of work at this level will impact and require resources from a
number of functional areas of the organisation (for instance launching a new customer selfservice website is not solely an IT project, there will be an IT component, marketing to promote
the use of the website, the service department to provide content for the knowledge engine, etc).
The portfolio process varies from organisation to organisation but should follow a clearly
understood process and provide guidelines to[3]:
1.
2.
3.
4.
5.
Keep a running backlog of projects and actively manage the backlog based on new
project requests and completed work
Where the work to be undertaken crosses multiple functional areas of the organisation and
breaks into logical streams of related but independent activities then manage that set of projects
as a Program of work.
Program Management
A program requires additional coordination to keep the interrelated streams of work synchronised
the advertising campaign needs to be ready to run when the software is completed, the call
centre staff need to be employed and trained before the advertising campaign launches, the
software needs to be on the production server before the advertising campaign launches etc.
The program manager should be a dedicated role who has the strategic view of all the streams
of work that must come together to deliver to overall program. The program manager provides
the unifying vision for the separate project teams who will work on different streams of work.
The program manager is the ultimate customer for all the project teams, and sets overall
priorities and milestones.
Program management is an adaptive process as the program of work will need to respond to the
changing realities of the organisation and the actual delivery and throughput of the separate
project teams.
An overall program plan should be produced and maintained as things change. Key elements in
the program plan include (ref Manage IT chapter 14 page 279):
o
o
Key milestones and high-level schedule for the program, including the ongoing release
cycle
Staffing profile across the various streams of work and time
Program management needs to provide direction for each of the streams of work. This is ideally
conveyed in a Product Vision that each team fully understands and commits to.
Problem/opportunity description and rationale why does this project matter to the
organisation?
What value will this project deliver to the organisation?
How does the project align with the organisations strategic goals?
Scope what is included and what is excluded from this teams responsibilities?
Key timelines that the project should deliver against
There are a number of simple tools that can be used in visioning workshops to help the
participants articulate and express the product vision. A few are listed below:
A simple matrix which articulates the strategic value that the product is intended to provide. The
matrix looks like the following table:
Primary
Increase Revenue
Secondary
Tertiary
(25% revenue
increase within 12
months of launch)
Reduce/Avoid Costs
Improve Service
(n/a)
(Increase customer
satisfaction rating by 20%
based on quarterly
satisfaction survey results)
(Other)
The goals of the project are expressed against the strategic drivers, there should only be one
primary driver and there might be a number of secondary or tertiary goals. Where there is more
than one goal in a column then they need to be ranked to avoid the everythings critical conflict.
Preparing this as a group activity helps the team to understand the clear and explicit focus for the
project.
Sliders
A tool for showing the priorities for the team across multiple dimensions.
The sliders range from Fully On to Fully Off if an element is On then it will be the strongest
factor that drives the decision making as the project continues. No two sliders can be set at the
same level, and the more sliders there are on the On side of the grid the higher the risk of
catastrophic failure this project accepts. Where there is little leeway in the project sliders then the
choice becomes deliver everything or deliver nothing, whereas more leeway allows for partial
delivery that contributes to the organisations goals.
Rob Thomsett describes the Slider tool in his book Radical Project Management.
Mike Cohn provides an online tool for setting sliders on his website
Scope Matrix
The in/out list is a simple tool that conveys clearly what will be done as part of this project, what
will not be done and where there is uncertainty about deliverables.
Where a topic is in the project team is responsible for delivery of this component.
Where something is explicitly out of scope the team will not spend any time or effort on this
component. If an out topic is something that the broader program of work is dependent on then
it is important that the responsibility for undertaking this work is clearly defined, the project
stream and person taking responsibility for ensuring this is delivered.
Where there is uncertainty about a topic being in scope or not then it goes into the Undecided
area. The team will not work on his piece and the product owner or project manager needs to
investigate further to identify if the piece of work is in or out of scope.
This tool is also explained in Radical Project Management, by Rob Thomsett.
Cost/Benefit Matrix
This should convey the level of uncertainty surrounding the estimates of both cost and benefit
the organisation will get from the project. Early in the project the costs will have a large Cone of
Uncertainty[5] and as the project progresses this will get narrower and narrower. It is likely that
the benefits also have a wide range of uncertainty. Uncertainty in both costs and benefits is not
necessarily a problem on a project provided the range is correct. Both costs and benefits should
be shown at three levels optimistic, likely and pessimistic. For example:
The figure in each cell is the net of benefit minus the cost.
This project should be considered high risk, as there is a distinct possibility that the organisation
will lose money on it. There might be other drivers which warrant the investment and the reward
profile if things go well is significant.
Undertaking cost/benefit analysis on a project is primarily a management level responsibility, but
the financial goals and drivers should be shared with the team.
Team members who join after the vision has been created need to be walked through the project
charter by someone who was present at the workshop(s) to help them understand the drivers
behind the work being undertaken.
Stewardship of the product vision is the responsibility of the product owner the person who
brings the business need to the project team. If during the execution of the project the
environment changes and the vision is no longer achievable or the organisation goals/drivers
change such that the project no longer delivers on them then the project should be stopped and
reassessed. Changes in the product vision are frequencly evidence of massive change in the
organisation ecosystem.
might impact the sequence of delivery (if we do this piece first then that piece will be easier to do
later).
The teams velocity is used as the starting point for the release planning activity. If this is the first
release then the velocity needs to be estimated, for subsequent releases then the actual velocity
from the previous release should be used (unless the team changes significantly between
releases).
Identifying the estimated velocity is initially a guess the more accurate the guess needs to be
the longer it will take to come to the answer. The simplest approach is to ask the team how many
story points they think they can deliver in an iteration and plan based on that number. It will
probably be wrong, but it could be a good enough starting point.
To get a better estimate of the teams capacity to deliver, use more thorough estimation
techniques, understanding that more accuracy costs more to achieve and may not provide
significant benefit for the cost incurred James King provides a useful estimation toolkit
downloadable from his website:
Once you have the estimated velocity this can be used to plan the iterations as follows:
1.
List the stories and epics for the release in priority order with their size in story points
2.
Decide (from your estimation activity) how many story points can be delivered in a single
iteration
3.
Consider the impact of non-story work the team may need to undertake (for example it is
common that early iterations will be slowed down by not having all the tools and environments
the team needs in place)
4.
5.
6.
Ask have all the stories been addressed and the release goals achieved
7.
If not then add a new iteration to the plan and repeat steps 5 &6
8.
Once all the stories have been allocated, socialise the plan and ask for feedback from the
team is it sensible and achievable.
This process can be seen as a flowchart:
The release plan is an adaptive plan it WILL change as the project progresses.
Once the release plan has been produced and agreed to it is used to guide the work in the
iterations.
The release plan is also used to produce the initial target velocity graph for the project.
The first activity is to examine the current release plan and update it based on any changes that
have happened since the last update. The beginning of iterations is where an Agile project
adapts changes are made to the plan based around the actuality of the project environment.
Specific things that impact the revised release plan are:
Actual velocity of the work delivered in previous iterations is it faster or slower than was
originally planned; changes in velocity define the scope of work that can be undertaken in the
Non-project work that reduces the teams ability to undertake project tasks
The first part of the iteration planning meeting is to identify the currently most important set of
epics and stories that the team will work on during the iteration. The product owner explains the
current priorities and the reason behind the changes, to ensure that the whole team has a clear
understanding of why priorities have changed.
Once the list of stories and epics has been reprioritised and everyone on the team understands
the revised release plan, the team builds the detailed iteration plan for the work to be done in this
iteration.
The team estimates how much they will be able to complete in the iteration based on
yesterdays weather (it is very likely that they will complete the same amount of work in the next
iteration as they did in the previous iteration, unless something has significantly changed in the
working environment or team makeup) and common sense. They then pick the stories to be
worked on for the iteration based on the capacity to deliver work.
Once the set of stories and epics to be worked on is identified then the team breaks the work
down into specific tasks for each team member task allocation is ideally done on a pull basis
whereby team members identify the work they are able to do and select their own tasks. Tasks
should be very small from a few hours to a day or so, and are discrete measurable activities.
The iteration manager (Scrum Master in Scrum) confirms that all the tasks are allocated and
performs a sanity check on the work being committed to is it likely that the team will be able to
deliver what they are committing to given the reality of the project environment?
Once tasks have been identified the team members sequence and estimate them. Estimation is
now at the level of hours of work needed to undertake a single task. These tasks could then be
written up on task cards and the task cards tracked on the storywall.
Tasks are linked to stories, and tracking a story from one state to the next on the storywall should
be accompanied by the completion of the task for that activity.
Tasks include every piece of work needed to complete the stories in the iteration, and to start
preparing for the next iteration.
The Iteration Backlog is the list of stories and epics which will be tracked on the story wall for this
iteration.
An example of a partial list of tasks is shown below:
Story ID
Task
Who
S123
Bob, Mary,
Peter, Steve
S123
Estimated Remaining
Actual
Hours
Hours
Hours
criteria
S123
Design UI
Peter, Steve, 2
Bob
S123
Code UI
Peter, Steve
S123
Code Middleware
Peter, Steve
S123
Code Database
Peter, Steve
S123
system
S123
S123
Mary
S123
Mary
S123
Bob, Mary
S123
Peter
S123
Bob
S124
Bob, Mary,
During the iteration team members report and track their work against the tasks. This is their
individual daily commitment.
A burn-down chart shows the initial estimate and remaining effort for the iteration. The actual
amount of time taken for each task can be tracked and used to help the team improve their
estimation in the next iteration planning meeting.
Daily Commitment
This is where the team members monitor their own progress and report against the tasks they
have committed to.
The Daily Standup is the primary communications tool for communicating progress within the
iteration. Every working day of the project the team gets together and reports to each other their
progress against the tasks they have committed to. The Daily Standup has a few simple rules:
It is held standing up
Maximum duration is 15 minutes
Each team member will speak for no more than one minute
Progress is reported against stories and tasks ONLY
Obstacles that are preventing a task from being undertaken or hindering progress are
reported separately
Each team member answers the following three questions:
o
What have you done since the previous meeting (with reference to the tasks, not
o
o
the current task within the timeframe that was estimated for it)
If there are issues to be addressed they will be taken up AFTER the daily standup it is
common for the daily standup to be followed by a few short one-on-one sessions to address
specific issues
The iteration manager is primarily responsible for getting the obstacles removed so the
team can be fully productive
An Agile project must be a safe to fail environment team members will not be punished for not
meeting task commitments. It must be safe to tell the truth about task status and to learn from the
actuality of the project environment. Sometimes we will estimate badly (it is an ESTIMATE not a
quote) or something will happen that prevents someone from working on their task the
environment must make if OK to report the truth, as that way team members can adjust their
schedule and sequence of tasks and adapt to the realities of the project.
When all the tasks for a story have been completed the story will move into the Done state, and
the project velocity is credited with the story points for that piece of work.
Conclusion
In preparing for battle I have always found that plans are useless, but planning is
indispensable. Dwight David Eisenhower
This table summarises the levels of planning and the involvement in the planning process at
each level:
Individual
Daily
Commitment
Individual
task plan
Team
Extended
Project
Team
Sponsor
PMO
Strategy Group
Iteration Plan
Release Plan
Product Vision
Define and
articulate
vision
Program
Review
Overall program
structure and
integration
Portfolio
Review
Pick which
projects to do
Influence
driven by
strategic goals
Strategy
Provide overall
Review
direction
Planning pervades Agile projects simple tools and safe environments support adaptive
planning and honest reporting which means progress is reported truthfully and management
have the information they need to make good decisions that enable the delivery of the best
outcomes for the organisation, team and project.
Agile planning takes into account that systems development is undertaken in complex and often
unpredictable environments and that flexibility and the ability to respond to change is paramount.
References
[1] We use the term predictive instead of the more emotive waterfall. Predictive projects are
ones in which the needs are not likely to change and where the work being done can be easily
identified and measured. An example of a predictive project would be the deployment of a new
operating system across all the computers in an organisation the amount of time and effort
needed for upgrading each computer is predictable and (to a certain extent) putting more people
on the work will result in a directly proportional reduction in the time needed. Adaptive projects
are those where requirements are likely to change and the work is largely creative with high
levels of uncertainty software development is an inherently adaptive process and does not
suite a predictive project framework.
[2] Alistair Cockburn provides a very valuable discussion of the meaning of Iterative and
Incremental iterative means subject to change, incremental means piece by piece. Agile
development is both iterative and incremental. See this link.
[3] Manage IT by Johanna Rothman Chapter 16, p 307
[4] Agile Project Management Sanjiv Augustine
[5] See this link
[6] Wallware refers to flipcharts, graphs, story cards and other artifacts that are prominently
displayed in and around the team space, they provide a visual record of the project, serving as
reminders of key decisions and visible to anyone who has an interest in the project. Other
commonly used terms are Information Radiators and Big Visible Charts.
[7] Story points are an estimation tool based on the relative level of effort and complexity involved
in delivering the product. Planning using story points takes advantage the power of collaboration
where each team members participates in evaluation of the user stories in terms of complexity.
Criteria such as difficulty of implementation, clarity of understanding and technical risks are
included in the estimate of the effort required to implement a particular story. This approach has
been found to o be much more effective than traditional one off estimates at the beginning of a
project.