Wednesday, September 29, 2010

Please describe the similarities and differences between UML and Object Diagram.

lass Diagrams and Object Diagrams use almost identical notations.  Both represent a static view of a system, however Object Diagrams represent a snapshot in time, whereas Class Diagrams are not time dependent and are an abstract view of the types of objects that may exist within a system, the relationships between them, and how and when one type of object can exist in relationship to another.  Since Object Diagrams represent specific object instances that exist at a single point in time, they are sometimes called Instance Diagrams.
A few notable differences in the notation and rules used to represent Class and Object Diagrams are:
  1. Class Diagrams represent each class via a rectangle and display up to 3 types of information; the class name (not underlined), its attributes, and its operations.  The Object Diagram also uses a rectangle to represent an object instance, however the object name is underlined and lists the name of the object followed by a colon and then the class name which describes its type (e.g.  Joe: Student, where Joe is the name of the object instance and Student is class).   Additionally the Object Diagram will list an object's attributes, but it will also list the value of that attribute at that point in time (e.g. SSN = 555-55-5555).
  2. Class Diagrams enforce multiplicity rules between associated classes.   For example, a Class Diagram may display an association between a Car and Passengers.  The Class Diagram would show a single rectangle to represent the class car and a single rectangle to represent the class passenger, but display multiplicities stating that each car may have 1..4 passengers.  An Object Diagram being a snapshot in time would show a rectangle for the Car and up to 4 separate rectangles, one for each passenger that exists at that movement in time.
  3. Many of the constraints or association types that exist in a class diagram have no relevance in an object diagram.  Multiplicities in a class diagram may constrain the number of passengers in a car to 4, but this rule would be enforced within the code itself such that a 5th passenger object could never be created.  Therefore, multiplicities are not shown within an object diagram.  Only the actual numbers of objects that exist at that moment in time are shown.  Similarly, other constraints such as "at least one passenger be of type driver" could also be captured and displayed in a class diagram but would not be shown in an object diagram since these rules are enforced within the actual code.

What is Scrum Method?

Scrum is one of several light-weight agile methods that use an iterative and incremental approach for the development of information systems.  The Scrum method brings a small team together to work on a specified set of features over a period of 30-days (called a sprint).
Both the term Scrum and sprint are borrowed from the sport Rugby.  A scrum is where the two teams are engaged in a huddled to begin play following a period where play has been stopped.  The fast moving period of play from the point of the scrum until play ends again is called a sprint.
The Scrum method starts each 30-day sprint with a kickoff meeting (a period where the entire team comes together).  The kickoff meeting lasts a full day and the features of the system to be developed are discussed.  The outcome of the kickoff meeting is a set of features that will be developed over the 30-day sprint along with estimates of how long the analysis and development of each feature will take.
In order for a feature to be considered completed, it needs to be Analyzed, Designed, Coded, Tested, Refactored, and Documented. If this life-cycle is not fully accomplished during the 30-day sprint, perhaps due to an initial underestimation of the time required, the feature will be pushed to a later sprint.
Following the kickoff meeting, and throughout the duration of the 30-day sprint, each day is started with a short meeting lasting approximately 15 minute called a daily scrum meeting (also called a daily stand-up meeting).  The purpose of this meeting is for the team to discuss what they accomplished the day before, what they will accomplish over the coming day, and to raise any obstacles that they have encountered that may impede progress.
One aspect of Scrum, that is intended to keep the Scrum team and method very agile, is its size.  Most Scrum teams consist of no more than about 7 people with each falling into 1 of 3 roles.
  • Product Owner – identifies the features that will be included in the next 30-sprint and set the priority of each.  This is typically a high-level stakeholder in organizations where a true Product Manger/Product Owner role doesn’t exist.
  • Scrum Master – acts much like the project manager.  While the Scrum Master does not micro-manage the teams deliverables, this person ensures that the 30-day sprint is on track and enforces the key rules that guide Scrum such as; no new features can be added to the sprint once it is kicked off, and team members cannot be pulled off to work on other side project in the middle of a sprint.
  • Team Member – unlike traditional software development methods, in Scrum there is little separation of duties between team members.  Each team member may fill the role of analyst, designer, coder, tester, and documentation writer.

What is meant by Agile? Describe:

Agile is a general term and conceptual framework used to describe a number of “light-weight” methodologies, such as Extreme Programming (XP), SCRUM, and Rapid Application Development (RAD), which exhibit a series of common characteristics.    Some of these characteristics include:
  • Iterative analysis and development
  • Time-boxed iterations of a predefined length
  • Delivery of the most critical features and functions first
  • Delivery of a complete build with an initial set of limited features within a few months (often 1-2 months)
  • Small cross-functional teams usually of 6-9 team members.
  • Daily team communication meetings
  • Reduced levels of documentation
Most Agile methods begin with a prioritized feature list where features are group together into deliverable chunks and assigned to a particular iteration in which they will be developed and delivered.  Using small teams and daily communication among all team members the Agile team can achieve a high level of efficiency.
Agile methods are intended to overcome or circumvent many of the recurring challenges that are encountered during software development projects.  The iterative nature of these methods, along with the desire to deliver smaller sets of defined features per iteration, help mitigate risk due to evolving requirements, unclear project stakeholder direction, and unforeseen project complexities that typically arise during the latter stages of analysis and development.    Some of the most salient advantages of Agile methods include:
  • Availability of working software much sooner which allows for more immediate feedback from application users.
  • More immediate, and therefore larger, Return on Investment from software features that are developed in short iterations and release to production immediately.
  • Less project overhead due to smaller team sizes.
  • Avoidance of large schedule overruns.
  • Avoidance of large budget overruns.

If there are no requirements, how will you write your test plan?

If there are no requirements we try to gather as much details as possible from:
·         Business Analysts
·         Developers (If accessible)
·         Previous Version documentation (if any)
·         Stake holders (If accessible)
·         Prototypes.