Welcome to EPF Wiki.


Most Recent

09:08 16 Jun 2014 - Develop Solution Increment in OpenUP

Should this be interpreted so that the activity appears twice because "develop solution increment" happens in two different contexts: One is development of the solution, the other development of the architecture (with the activity being the same, since the architecture can be considered a solution within the solution)?

08:47 11 Mar 2014 - Getting Started in OpenUP

I'm studying the Unified Process and learning how to use the EPC/RMC.

Could you point me to  any examples of projects modeled using UP
- real or somewhat simplified examples of projects.

Thank you very much.

09:52 19 Nov 2013 - Scrum Overview in Scrum PT


06:21 08 Oct 2013 - Work Products in OpenUP

mahak software

03:55 30 Sep 2013 - Develop Product Documentation in OpenUP

Users often forget the business rules and logic inside complex business software, so it does really help to document this. This doubles as a training tool to orient new users.

Try to spend your time documenting vague, hidden, or complex features of the software, like showing some possible ranges of input for a text box rather than bore the reader with stuff they can probably figure out for themselves.

Mobile apps by nature have simple GUI's so hopefully they are designed to need little documentation for users to start using them, or in other words the GUI should be designed in a way that orients the user to the available functionality and promotes a clear sequence of steps for them to perform their task.

17:19 12 Sep 2013 - Writing Requirements Statements in OpenUP

This is a good article outlining the basic rules that you should follow when writing requirements.

However I believe that it also important to mention that meta data is critical for requirements such as priority, responsible stakeholder etc.

There is a blog that describes this in more detail here:


08:07 28 Aug 2013 - Estimation Techniques in Scrum

I wanted to add a reference to a free scrum poker android app, but the page is locked. So here it is:


08:18 11 Aug 2013 - OpenUP/Basic Work Products in OpenUP SP

prueba 1

10:05 08 Apr 2013 - Scrum Roles in Scrum

El equipo encargo en desarrollar  proyecto de Software

01:24 01 Mar 2013 - Scrum Overview in Scrum

test reply


00:55 01 Mar 2013 - Scrum Overview in Scrum

test discussion

12:09 01 Oct 2012 - Deployment in OpenUP

Little "a" agile.

12:03 01 Oct 2012 - Deployment in OpenUP

What happened to the agil, low-ceremony process?

15:07 12 Sep 2012 - Develop Product Documentation in OpenUP

Do we really want to continue top develop software which requires detailed documentation?  How much documentation did you read before using the latest version of your favorite operating system?  Or did you dive in after (or without) watching the 30-second online tutorial?  

How many apps do you have on your phone, which you regularly use but for which you've never read the docs?  

I offer that any need for product documentation is testament to the failure to design a usable solution. 

People need training in the terminology and business process of the work that they do with software, and if our software mirrors their expectations and terminology, they should require no training on how to use our software.

There is another reason user documentation should become extinct: users have changed.  Once upon a time most people who worked on computers never saw one except at work, the green screens required memorization of codes (think about flying from YVR to LGW via JFK) and a wrong code offered a cryptic error message because the system was interconnected to ... only itself.  Today users have computers in their pocket or purse which litsne to satellites in orbit and interconnect with mainframes around the globe.  They create their own codes on the fly, IMHO.  We don't need to teach them what PF4 does or the difference between click and drag.  What we need to do is to build solutions which leverage what they already know ratrher than teach threm new ways to do what they already know how to do.  And if our solution is adding value, their work should include significantly fewer steps than what they did before this latest release (which implies the user doc may only need to tell them what not to do).. 

This makes tremendous economic sense:  we know from studies that about half of the features delivered are never used, so it makes sense to build about half as much software to deliver the same business value.  That means the features delivered are expected to be used, which means the case for their usage should be apparent and they can be made to conform to the usage, eliminating the time and cost of documentation development, testing, and maintenance.

There remains a strong case for documentation to support the needs of installers, administrators, and operations staff because those folks use the software infrequently and as one of many systems they install, administer, or operate.  The style and extent of such documentation may differ significantly from what we wite for users, and the maintenance is generally less expensive since installation, admin, and operations procedures for a given system tend to change less frequently than its functional or quality features.

08:00 10 Sep 2012 - Scrum Overview in Scrum PT

Verificando como ele publica