Agile/Scrum techniques for Big Project:

Scrum techniques:

If the project are big or other words if the huge number of User stories have been created; how do manage such big project through agile. Is agile is right way to adopt, is agile will be successful than any other model.

So many question and no confirm answer.

Let start with first step from agile and digging out some answers which might be helpful to make the decisions.

1. Agile means Epic-US-Task-Coding-testing-Features Ready.

2. Product Owner and SM working togther to get above things done with stakeholder and product manager.

3. Now questions started

• Can features will be ready without Testing - No it can not be
• Can testing be done without Coding - No it can not be
• Can Coding will be done without task creation - Might be (yes/No)
• Can task will be created without complete US - No it can not be, here i am saying complete US means, US details/COS and clear understanding of the US; if any US bring into the sprint without all these it will impact the sprint velocity, resources utilization and product owner effort as well. So these kind of US can not bring in any sprint.
• Can US will created without EPIC/requirement - No it can not be

So overview of the above details means US (Product Backlog) needs to be created, COS needs to defined and US should be completed (publsihed) ahead of the task creation.

My opinion All known US needs to be written and published before coding started.

This is something like Army needs to go for some operation before that planning and trial needs to be done. On the decision day it is just matter of time for the expert to execute the plan, take any big Army execution as an example.

So decision day start when you bring the development team into the game until than it is just planning with product owner, product manager and stakeholder.

This way organization can save time, money and more than that utilization of resources

4. Calculating the velocity will help along with resources capacity planning as well.
If team sprint velocity is "X" and resource capacity is "Y" after calculating resource capacity SM will get some number (velocity) which can be either "X" or "X+Z"; this new number can not be "X-A" since team can not be less than thier velocity.
This activity will help SM to project the rest of work as well.

5. Try to avoid creation of any additional  US based on the velocity.

6. Team should alwyas have at least 6 to 8 sprint (2 weeks sprint) work.

7. Every team member can shadow each other or back up should be ready within in a team to take over the sprint work.

8. Last but not least have 90%  to 95% US completed before decision day started.

9. try to create Small features and tied these features to pre releases.

10. Pre-releases date can not be move in any conditions

11. Add one product owner as Scrum says but keep many analyst which is equivalent to product owner (Proxy Product Owner) but they will work with Product Owner to create and validate US so team utilization.
This activity will help department and team for better utilization of resources and budget utilization as well.

Some do and don't while running such big projects.

Do
1. User stories needs to be maintain by Product Owner/Product Manager
2. Only Product owner can add or delete the US.
3. Scrum Master should talk to Product owner for any new US.
4. Every US must have tasks.
5. Expolaroty testing can be fit for agile development.
6. Product owner should signed off for every Sprint.
7. Every Epic/US should have some points (example poker points) assigned to it.
8. Changed any completed US COS with approval of Product Manager with additional Poker Points.
9. Define small points to any US, that can be done during in sprint.
10. Create couple of Sprints for UAT and Production planning.

Don't
1. During the Sprint trying to avoid take US.
2. Don't do any POC during the sprint.
3. COS and US details needs to be clear so team can understand very well.
4. Dont assigned big points to any US
next article: Agile and EA and other architecture

Enterprise Model and Agile Testing

AGILE Testing and Enterprise Model of Agile

Uses, Include and extends

uses, Include and extends:

uses
The uses arrow (or uses edge as it would be called in traditional graph thoery) is drawn from a use case X to another use case Y to indicate that the process of doing X always involves doing Y at least once (although it may involve doing it many times, "at least once" is the only relationship guaranteed by this symbol.) This symbol can be referred to as an aggregation operator, because it indicates that a given use case is an aggregate (made up of parts) whose components are the use cases that it uses. If a certain use case uses several others, that means that all of the component use cases must be completed in the process of completing the aggregate use case, although there is no specification in UCDs of the order in which these are completed. A brief, mnemonic way to think about the uses arrow is that it it can be read X uses Y means that "X has a Y" as part of it's behavior.

Include and extends:

The correct way to indicate a "include" or "extend" relationship is with a dashed line. Now the difference between the two is the following. 

Suppose A includes B. This means that whenever somebody does A she will do B too. On the other hand, if A extends B, than whenever somebody does A, B has nothing to do with it. But if you do B, you might do A additionally during the course of B. You should specify a condition under which A actually extends B.

In this case both can be use as long as indicate in the condition of the extends version that this depends on the customer being new.
BTW "subclassing" is not the correct term, it is (again) generalization. Adding such a generalization implies that every new customer is a customer and can do whatever a regular customer can do.

Relationships are dependencies
The key to Include and extend use case relationships is to realize that, common with the rest of UML, the dotted arrow between use cases is a dependency relationship. Use the terms 'base', 'included' and 'extending' to refer to the use case roles.

include:

Include is used to extract use case fragments that are duplicated in multiple use cases. The included use case cannot stand alone and the original use case is not complete without the included one.

A base use case is dependent on the included use case(s); without it/them the base use case is incomplete as the included use case(s) represent sub-sequences of the interaction that may happen always OR sometimes. ( This is contrary to popular misconception about this, what your use case suggests always happens in the main scenario and sometimes happens in alternate flows simply depends on what you choose as your main scenario; use cases can easily be restructured to represent a different flow as the main scenario and this should not matter).

In the best practice of one way dependency the base use case knows about (and refer to) the included use case, but the included use case shouldn't 'know' about the base use case. This is why included use cases can be: a) base uses case in their own right and b) shared by a number of base use cases.

extend:

Extend is used when a use case conditionally adds steps to another first class use case.

The extending use case is dependent on the base use case; it literally extends the behaviour described by the base use case. The base use case should be a fully functional use case in its own right ('include's included of course) without the extending use case's additional functionality.

Extending use cases can be used in several situations: a) The base use case represents the "must have" functionality of a project while the extending use case represents optional (should/could/want) behaviour. This is where the term optional is relevant - optional whether to build/deliver rather than optional whether it sometimes runs as part of the base use case sequence. b) In phase 1 you can deliver the base use case which meets the requirements at that point, and phase 2 will add additional functionality described by the extending use case. This can contain sequences that are always or sometimes performed after phase 2 is delivered (again contrary to popular misconception). c) It can be used to extract out sub sequences of the base use case, especially when they represent 'exceptional' complex behaviour with its own alternative flows.

One important aspect to consider is that the extending use case can 'insert' behaviour in several places in the base use case's flow, not just in a single place as an included use case does. For this reason it is highly unlikely that an extending use case will be suitable to extend more than one base use case.

As to dependency, the extending use case is dependent on the base use case and is again a one way dependency, i.e. the base use case doesn't need any reference to the extending use case in the sequence. That doesn't mean you can't demonstrate the extension points or add a x-ref to the extending use case elsewhere in the template; but the base use case must be able to work without the extending use case. 

1. Association is a relationship where all objects have their own lifecycle and there is no owner.
• example of Teacher and Student. Multiple students can associate with single teacher and single student can associate with multiple teachers, but there is no ownership between the objects and both have their own lifecycle. Both can be created and deleted independently.
2. Aggregation is a specialized form of Association where all objects have their own lifecycle, but there is ownership and child objects can not belong to another parent object.
• example of Department and teacher. A single teacher can not belong to multiple departments, but if we delete the department, the teacher object will not be destroyed. We can think about it as a “has-a” relationship.
3. Composition is again specialized form of Aggregation and we can call this as a “death” relationship. It is a strong type of Aggregation. Child object does not have its lifecycle and if parent object is deleted, all child objects will also be deleted.
• example of relationship between House and Rooms. House can contain multiple rooms - there is no independent life of room and any room can not belong to two different houses. If we delete the house - room will automatically be deleted.

Reference: 

1. https://www.geeksforgeeks.org/java/association-composition-aggregation-java/

Configuration Maven and JBOSS

Configuration Maven and JBOSS


Configure Maven
Step1:
Open Environment Variables

Step2:
Create New System Variables
Maven Home parameter: M2_HOME
Value "maven root directory"

Step3:
Enter the below value in path ;%M2_HOME%\bin;

Step4:
Apply and ok

Verification:
Open maven bin directory and type command
mvn -version

Configure JBOSS 7.1

step1: download JDK1.6 or above

step2: install JDK

step3: create JAVA_HOME

step3.1 :
Open Environment Variables

Step3.2:
Create New System Variables
JAVA Home parameter: JAVA_HOME
Value "Java root directory"

Step3.3:
Enter the below value in path ;%JAVA_HOME%\bin;

Step3.4:
Apply and ok

After installing Java and Maven download JBOSS 7.1 and unzip and run the command standalone.bat from bin directory.

Now all set to use JBOSS.

http://www.youtube.com/watch?v=zkNyEXArwwI

http://www.jboss.org/jdf/quickstarts/jboss-as-quickstart/guide/GettingStarted/#_installing_and_starting_the_jboss_server_on_windows

Maven vs Ant

Maven vs Ant.

This article provides difference between two tools and why in one case you choose Ant and in another Maven. It help to make a choice between two Java build tools.

developers usually prefer one tool over another because:

1. Develop faster
2. Concentrate on real work
3. Generate all related document easy

developer also prefer one tool over another to keep our bosses happy, which means:

1. Reduce development costs
2. Reduce time to market
3. Frequent status reports, which can be easily presented to higher boss

Ant is older tool and it was deigned to have some Java-based build tool. Something similar to Make which most of C++ developers use.

Ant is different. Instead of a model where it is extended with shell-based commands, Ant is extended using Java classes. Instead of writing shell commands, the configuration files are XML-based, The power of Ant in practice results that you have to setup build process yourself. Each project can have different build process. New team members have to study this version of build which is probably they used to have in another project.

Maven (Maven)on another hand wants a standard way to build the projects, a clear definition of what the project consisted of, an easy way to publish project information and a way to share JARs across several projects.

Maven encourage best practices and some people can prefer Ant. Ant is less flexible than Maven and you have to be agree with making of some compromises.

Maven is not the next generation Ant!
Maven is not just a building tool, it provide an organization and a structure layer. All you do in ant can be done in Maven because you can call ant target.

The main advantage to migrate to Maven are : standardization of how to handle a project, dependencies are clearly defined, the concept of artifacts that can be shared to other projects, documentation and reports, remote and local repository concepts.

Maven will help you with:

1. Making the build process easy and provide uniform build environment
2. Generate quality project information

Major advantages/disadvantages - Maven vs Ant.

Maven
1. Description of project Development of a build script per project
2. Invocation of defined goals (targets) Invocation of project specific targets
3. Project knowledge "Just" the build process
4. build life cycle, standard project layout too complex scripts
5. reusable plugins, repositories scripts are not reusable
6. moving fast forward development are slowed down
7. Maven is declarative, Â Maven takes care of all the directories once the files are stored in the pom.xml file.
8. Maven has a life cycle.

Ant
1. Development of a build script per project
2. Invocation of project specific targets
3. "Just" the build process
4. too complex scripts
5. scripts are not reusable
6. development are slowed down
7. Ant is procedural. In Ants, you have to specifically order what should have to be done.
8. Ant does not have a life cycle.

The good thing with Maven that it is extremely flexible, because it consists of core and numerous plugins that are accessible in online repositories. Relations between different projects and subprojects are based on a single source of information POM (xml) file - Project object Model. One POM points to another POMs which can have flat or hierarchical structure.

A project produces an artifact - jar, ear, war...

Maven features:

1. Dependencies are downloaded automatically
2. Standardized, very consistent layout
3. Standardized, very consistent naming
4. Code coverage
5. Extensive reports
6. Maven easily works with JUnit tests


http://www.javafaq.nu/java-article1168.html

http://www.scribd.com/doc/19172721/A-Brief-Comparison-of-ANT-MAVEN

Spring Framwork Tutorial

Spring Framwork Tutorial


http://www.youtube.com/watch?v=DfMjxfwV5_s&feature=relmfu

SAML and Security

SAML and Security


Federation:
Federation describes scenarios in which no group or organization manages all users and resources in a distributed application environment. Instead, administrators in diverse domains must manage local security policies that support mutually beneficial transactions among their respective spheres of operation. In the world of distributed network services, the term refers to the need for trust agreements among decentralized security and policy domains. Federation lets access-management functions span diverse organizations, business units, sites, platforms, products and applications. Federation requires that an organization trust each trading partner to authenticate its own users' identities. In a federated environment, a user can log on to his home domain and access resources transparently in external domains, such as those managed by customers or suppliers, subject to various policies defined by home and external administrators.Federation used with a new security standard, the XML-based Security Assertions Markup Language (SAML). The standard defines XML/Simple Object Access Protocol-based protocol interactions that support real-time authentication and authorization across federated Web services environments. The standard defines request and response messages that security domains use to exchange authentication, attribute and authorization information in the form of trust-assertion messages about named users and resources. Users log on to their home domains through authentication techniques such as ID/password or Kerberos, and this authentication is communicated to a federated destination site through a SAML authentication assertion.

How SAML works

One of the most important of those security issues is user authentication - specifically, allowing a user to sign on or use multiple Web services from separate but affiliated sites, without having to authenticate himself at every step of the process. That's the job of SAML (Security Assertion Markup Language), an XML-based standard for authentication and authorization that provides a "single sign-on" so that people can be authenticated once and then be able to access multiple Web services. SAML allows each individual site to have its own mechanism for sign-on and authentication, but will allow sites to accept authenticated users from other sites.

Why SAML is needed

Before we take a look at how SAML works, let's take a look at why it's needed. Let's say someone visits an airline site with a Web services architecture, and reserves tickets after signing on and being authorized to buy the tickets. The site offers special deals with partner sites on hotel stays and car rentals, and so the user decides to make reservations with them. In order to make reservations with each of those partner sites without SAML, the person will have to sign on separately to each site, using different user names, passwords and authentication information. He also might have to enter special codes that say he is entitled to the special deals. But with SAML, the person would only have to sign on to the first site, and he would then automatically be authenticated via SAML at the affiliated sites.Even more problematic are complex B2B transactions done via Web services. Web services will most likely be used in automated transactions that involve multiple business partners, including manufacturers, distributors, packagers, suppliers and retailers. With no way to authenticate each partner and what they can and can't do in a transaction, these transactions won't be able to be done automatically. With SAML handling authentication, complex transactions can be automated without worrying about authentication problems.

SAML Implementation

So how does SAML tackle all this? At its base, SAML is nothing more than a series of XML-based messages that detail whether users are authenticated, what kind of rights, roles and access they have and how they can use data and resources based on those rights and roles. It will work with HTTP, SMTP, FTP and SOAP, among other protocols and technologies.

The three main components of the SAML specification are:

Assertions SAML has three kinds of assertions:
1. Authentication assertions are those in which the user has proven his identity.
2. Attribute assertions contain specific information about the user, such as his spending limits.
3. Authorization decision assertions identify what the user can do, for example, whether he can buy an item.

Protocol:
This defines the way that SAML asks for and gets assertions, for example, using SOAP over HTTP for now, although using other methods in the future.

Binding: This details exactly how SAML message exchanges are mapped into SOAP exchanges.

The assertions are exchanged among sites and services using the protocol and binding - and those assertions are what authenticates users among sites.

SAML in real life

How does SAML work in real life? Let's take a real-life example. Say someone logs in and uses a Web service, is authenticated and then wants to go to a partner site. With SAML, he can be authenticated at the second site without having to sign on. The nearby figure shows each step of the process:

Step 1 the user has authenticated himself with Site 1 and wants to visit Site 2. He clicks on a link to go to Site 2.In

Step 2, instead of being sent straight to Site 2, he is instead sent to the SAML service for Site 1.

Step 3 the SAML service appends a partner ID and a special handle to Site 2's URL in the user's browser.
For example, if the user wants to go to the site http://www.buymenow.com, after the SAML service appends the extra information, the URL might now be https://www.buymenow.com?SAMLart=. Note that the protocol has changed to the secure https instead of http. The user is redirected now to Site 2's SAML service, which examines the URL with the appended information. Based on the information in the URL, Site 2's SAML service communicates with Site 1's, and Site 1 sends along the authenticated identity of the user, along with any rights that the user has.

Step 4 the user is sent to Site 2, fully authenticated. The user can now perform transactions on the site just as if he had logged directly into the site.

The future of SAML

SAML is not yet a fully accepted standard. OASIS, the consortium that develops XML standards, is expected to accept the first official SAML standard this summer or late spring. Sometime in the fall, you can expect products to be available that can make use of the accepted spec.As with all standards, though, expect some problems. It's unclear whether a Web service built using an early version of SAML will be able to completely work with a Web service built using a later version. Considering that SAML 1.0 hasn't even been accepted yet, it's a moot point right now, but could be problematic in the future.A bigger potential issue is whether Microsoft will buy in to the spec. Even though Microsoft is an OASIS board member, it's working on its own separate authentication protocols, known as WS Security and WS License. If Microsoft decides to continue work on them and use them as an alternate to SAML, all bets are off as to how useful the protocol will prove in the long run.

AD and LDAP


Active Directory is a database based system that provides authentication, directory, policy, and other services in a Windows environment

LDAP (Lightweight Directory Access Protocol) is an application protocol for querying and modifying items in directory service providers like Active Directory, which supports a form of LDAP.

Short answer: AD is a directory services database, and LDAP is one of the protocols you can use to talk to it


Active directory is a directory service provider, where you can add new user to a directory, remove or modify, specify privilages, assign policy etc. Its just like a phone directory where every person have a unique contact number. Every thing in AD(Active Directory) are considered as Objects and every object is given a Unique ID.(similar to a unique contact number in a phone directory.

Ldap is a protocol specially designed for directory service providers. Windows server OS uses AD as a directory server, AIX which is a linux version of IBM uses Tivoli directory server. Both of them uses LDAP protocol for interacting with directory.

Apart from protocol there are LDAP servers, LDAP browsers too.


reference: http://searchsoa.techtarget.com