Sunday, February 15, 2009

Product Lifecycle Management (PLM)

What is PLM? - (Excerpt from PLM Technology Guide)

Product lifecycle management or PLM is an all-encompassing approach for innovation, new product development and introduction (NPDI) and product information management from ideation to end of life. PLM Systems as an enabling technology for PLM integrate people, data, processes, and business systems and provide a product information backbone for companies and their extended enterprise.

Business Drivers

Innovation and new product development are essential for most companies to sustain future revenue growth. Customers demand more new products in shorter time intervals, often customized to their own needs. They want more attractive designs, better performance, better quality, lower prices, and instant availability. To meet these needs companies have to be able to collaborate closely within their own organization and with partners and suppliers located in various parts of the world. At the same time companies have to manage increasing product and manufacturing complexities due to a quickly growing number of environmental and regulatory rules and requirements.

The Problem

Accelerating innovation and increasing the number of successful new product introductions is a huge challenge for most organizations today because of their traditionally serial, fragmented, manual, and paper based processes. The result is that many companies suffer from NPDI practices that are slow, resource intensive, costly, inflexible, provide little visibility, and are difficult to manage and control.

The Solution – PLM

Through their ability to integrate all product related data and processes and to eliminate boundaries in the value chain, PLM Systems can significantly reduce non-value added activities and enable stakeholders to collaborate in real time using a consistent set of information throughout the entire product lifecycle.

As a result, productivity improvements of over 60% in NPDI-related activities have been achieved through PLM-enabled, enterprise-wide data and process optimization and integration that have allowed companies to:

  • Drive innovation
  • Accelerate Revenues
  • Increase Productivity
  • Reduce Costs
  • Improve Quality
  • Ensure Compliance
  • Shorten Time-to-Market

In today’s highly competitive, fast-paced and global business environment, well-designed and implemented PLM practices, processes and technologies that support an organization’s strategies for innovation and growth can afford companies a real competitive advantage.

Reference URLs:

PLM Technology Guide

10 Best Practices for Successful PLM Evaluations

PLM from Wikipedia


Oralce Accquire PLM Company



Monday, February 9, 2009

Unified Process vs Agile Process

What is UP? Definition from Wikipedia - IBM RUP
What is Agile? Definition from Wikipedia - Agile software development


Comparison of UP & Agile

"
Software development processes define a list of activities to undertake, what order the activities should proceed in, what the inputs and outputs of each activity should be, etc. What few software process specifies is when to stop. It’s often too easy to overuse a process, and continue to produce system designs, resulting in a heavyweight, document centric process. Essentially, process is followed for process sake, rather than adding value to the stakeholders of the project.

Although UP is iterative, it follows the general phases of inception, elaboration, construction, and transition in a more or less linear fashion. As the development proceeds less time is spent on requirements and analysis, and more time is spent on construction, testing, and transition.

Agile processes on the other hand, spend time on each activity in each iteration. During each iteration (usually 2-4 weeks) a little of all steps (requirements, analysis, design, development, test, etc.) are undertaken. The goal is to have stable software which could be shipped at the end of each iteration. At the beginning of each iteration, all stakeholders meet to reorganise requirements and their priorities, while at the end of the iteration, working software is demonstrated to the stakeholders. This ensures that customer value is being added at all times, and that progress is being made on what matters, working software.

UP and its relative the Rational Unified Process (RUP) are quire comprehensive, and were designed to be modified to suit the project being developed. This adds another layer of complexity to the development effort, as the process has first to be modified before being implemented. While this allows for the flexibility to use UP on any project, it requires teams to have access to UP experts to ensure that the process is being defined and used properly.

Agile on the other hand tends to be used for small to medium sized projects involving teams up to 10 closely knit developers. Once teams become bigger than this, agile methodologies begin to fail, as they don’t scale to large teams, or teams spread across geographies." - from chris blog

Which one is better and which one to use?

like what chris said in his blog "there is no silver bullet, or one size fits all approach. You need to tailor the process to the project and your individual circumstances. " Agile strike a good balance between process and productivity, but there is some project out there where agile may be an inappropriate process of choice. RUP is great, but you have to have experienced people doing RUP projects as you don't want to overload everyone with documentation, but also have to carefully look at what the customer wants.

One important difference (from dennis) between UP & Agile is that communication in UP is more through documents where as in Agile it's face to face communcation between the customer and the entire team.


SCRUM - What is SCRUM? Definition from Wikipedia - SCRUM

Scrum is an iterative incremental process of software development commonly used with agile software development.

Although Scrum was intended to be for management of software development projects, it can be used in running software maintenance teams, or as a program management approach.

Scrum is a process skeleton that includes a set of practices and predefined roles. The main roles in Scrum are the "ScrumMaster" who maintains the processes and works similarly to a project manager, the "Product Owner" who represents the stakeholders, and the "Team" which includes the developers.

During each "sprint", typically a 2–4 week period (length decided by the team), the team creates an increment of usable software. The set of features that go into a sprint come from the product "backlog", which is a prioritized set of high level requirements of work to be done.

Scrum enables the creation of self-organizing teams by encouraging co-location of all team members, and verbal communication across all team members and disciplines that are involved in the project.

A key principle of Scrum is its recognition that during a project the customers can change their minds about what they want and need (often called requirements churn), and that unpredicted challenges cannot be easily addressed in a traditional predictive or planned manner. As such, Scrum adopts an empirical approach—accepting that the problem cannot be fully understood or defined, focusing instead on maximizing the team's ability to deliver quickly and respond to emerging requirements.

There are several implementations of systems for managing the Scrum process which range from yellow stickers and whiteboards to software packages. One of Scrum's biggest advantages is that it is very easy to learn and requires little effort to start using.

Scrum Meetings

Daily Scrum
Each day during the sprint, a project status meeting occurs. This is called a "scrum", or "the daily standup". The scrum has specific guidelines:

* The meeting starts precisely on time. Often there are team-decided punishments for tardiness (e.g. money, push-ups, hanging a rubber chicken around your neck)
* All are welcome, but only "pigs" may speak
* The meeting is timeboxed at 15 minutes regardless of the team's size
* All attendees should stand (it helps to keep meeting short)
* The meeting should happen at the same location and same time every day

During the meeting, each team member answers three questions:

* What have you done since yesterday?
* What are you planning to do by today?
* Do you have any problems preventing you from accomplishing your goal? (It is the role of the ScrumMaster to remember these impediments.)

Sprint Planning Meeting
At the beginning of the sprint cycle (every 15–30 days), a "Sprint Planning Meeting" is held.

* Select what work is to be done
* Prepare the Sprint Backlog that details the time it will take to do that work
* 8 hour limit

Sprint Review Meeting
At the end of a sprint cycle, two meetings are held: the "Sprint Review Meeting" and the "Sprint Retrospective"

* Review the work that was completed and not completed
* Present the completed work to the stakeholders (a.k.a. "the demo")
* Incomplete work cannot be demonstrated
* 4 hour time limit

Sprint Retrospective

* All team members reflect on the past sprint.
* Make continuous process improvement.
* Two main questions are asked in the sprint retrospective: What went well during the sprint? What could be improved in the next sprint?
* 3 hour time limit

Please refer to wikipedia for more about role, artifaces in scrum

Scrum is kind of adaptive project management and here are some general practices of Scrum:

* Customers become a part of the development team (i.e. the customer must be genuinely interested in the output.)
* Scrum has frequent intermediate deliveries with working functionality, like all other forms of agile software processes. This enables the customer to get working software earlier and enables the project to change its requirements according to changing needs.
* Frequent risk and mitigation plans are developed by the development team itself—risk mitigation, monitoring and management (risk analysis) occurs at every stage and with commitment.
* Transparency in planning and module development—let everyone know who is accountable for what and by when.
* Frequent stakeholder meetings to monitor progress—balanced dashboard updates (delivery, customer, employee, process, stakeholders)
* There should be an advance warning mechanism, i.e. visibility to potential slippage or deviation ahead of time.
* No problems are swept under the carpet. No one is penalized for recognizing or describing any unforeseen problem.
* Workplaces and working hours must be energized—"Working more hours" does not necessarily mean "producing more output."



Reference URLs:

Agile Modeling and the Rational Unified Process (RUP)

Agile vs. RUP

Unified Process vs Agile Processes

Google Tech Talks - Srcum

Friday, February 6, 2009

EclipseLink

EclipseLink is an open source object-relational mapping package for Java developers. It provides a powerful and flexible framework for storing Java objects in a relational database or for converting Java objects to XML documents.

EclipseLink's original contribution came from the Oracle TopLink product in 2006.

EclipseLink supports several standard persistence related APIs including:

EclipseLink provides support for:

  • Object relational mapping (ORM)
  • Object XML mapping (OXM)
  • Object persistence to Enterprise Information Systems (EIS)
  • Database web services

Sun Microsystems has selected the EclipseLink project to be the reference implementation for JPA 2.0.[1]

Reference List:

Webnar: http://live.eclipse.org/node/490
Wikipedia: http://en.wikipedia.org/wiki/EclipseLink
Introduction of SDO
Introducing EclipseLink
EclipseLink Team Blog

EclipseLink/UserGuide

´