Portal:NiCE_Training

Table of Contents

• NiCE Development Team Training

Software Development Process

Object Oriented Analysis

Unified Modeling Language

Test Driven Development

NiCE Individual Team Flow

NiCE Development Team Training

Software Development Process

_ The development of any quality product requires thoughtful consideration, construction, testing, and deployment by a dedicated team of individuals working in concert _

NiCE development is a strict realization of the above statement, and as such, strives for the thoughtful consideration, construction, testing, and deployment of NiCE in all NiCE Development Team activities. Consideration includes thorough team planning and the development of an on-going relationship with NiCE stakeholders to understand their stringent requirements throughout modeling and prototyping. Construction includes up-front analysis and design before implementing actual product code. Additionally, it promotes software version control, as well as modern software development best-practices such object-orientation and test-driven development. Deployment includes a quality-oriented, customer-focused effort to document all facets of the product and its development and ensure a timely release of the product.

NiCE utilizes a software development process that facilitates the realization of this overall philosophy. The process is top-down, iterative, model-based, and use case driven. The development of a system model that traces directly to gathered stakeholder requirements enforces a strict adherence to thoughtful design and analysis. The NiCE development process is a tailoring of IBM's Model Driven Systems Development (MDSD), a derivation of the Rational Unified Process (RUP). As such, it is a process that is conducive to team collaboration as well as extremely adaptable to any future stakeholder requirement changes or requests. The following describes the basic pillars of the NiCE software development process:

• Top-Down Design

  NiCE is developed from a top-down perspective and begins with the compilation of a system or product vision. This vision defines the overall scope of the product to be developed, and focuses on system stakeholder definitions, functional requirements, external tools to be leveraged, and why the product is needed at all. Once the vision is established, formal interviews are held with stakeholders and subject-matter experts to gather all necessary system requirements. These requirements are then used to develop a set of formal system use cases, or actions of value that a user can get from a system. These use cases drive the development of a system black box UML model, detailing the system information architecture at the highest level, as well as the basic flow of user-system interaction. This methodology is in stark contrast with the alternate bottom-up development, which focuses on the development of aggregate sub-pieces of a system, and the subsequent interaction of those pieces to achieve macroscopic behavior. It is the belief of the Nice Development Team that this bottom-up development is a myth, and that software developed in this way can not stand the test of time.

• Iterative Development

  NiCE development is to occur in repeated iterations (for example, one month for NiCE development) to promote system and development adaptability. Each iteration development flows down from initial requirements analysis, to system and test modeling, then finally to system and test prototypical code. This allows stakeholder requests and requirements to be dynamic, while not decreasing development productivity or causing complete system overhauls.

• Model Based Design

• Use Case Driven
• Testing and Continuous Integration
• Documentation

Object Oriented Analysis

• Abstraction
• Encapsulation
• Modularity
• Hierarchy

Unified Modeling Language

Detail UML and its components, give picture examples

Test Driven Development

Describe TDD with Activity Diagram

NiCE Individual Team Flow

When fixing a bug or adding a feature to NiCE, the following steps should be followed:

• File a task in the SourceForge Tracker
• Jay Billings reviews the bug fix or feature request and delegates the task accordingly
• Appropriate team member fixes the bug or adds the feature:
  • Request any necessary changes to the use cases, model, or IT infrastructure from Jay Billings
  • Update the model per guidance
  • Transform the UML model to source
  • Fix the tests firsts, then fix the product code to comply with those tests (See Test Driven Development)
  • Report the fix to other team members for review
  • Commit the fix or feature to the repository
• Jay Billings and the team member mark the bug fix or feature add as complete