Docstoc

Process wiki.xlsx - MSE Studio

Document Sample
Process wiki.xlsx - MSE Studio Powered By Docstoc
					Name       Modified By   Created By   Created




AUP.aspx   Raúl Véjar    Raúl Véjar    10/4/2008 16:12
Chief Architect.aspx   Adlan Israilov   Adlan Israilov       5/18/2009 19:41




Client Liaison.aspx    Adlan Israilov   Andrew O Mellinger   12/7/2008 11:14
Configuration Management.aspx   Adlan Israilov   Raúl Véjar           9/13/2008 15:14




Conflict Resolution.aspx        Adlan Israilov   Andrew O Mellinger   10/5/2008 16:04
Construction.aspx   Raúl Véjar   Raúl Véjar   10/4/2008 18:07
Decision Making.aspx   Majid Alfifi   Andrew O Mellinger   10/5/2008 15:25
Deliverables.aspx   Adlan Israilov   Raúl Véjar   10/4/2008 17:50
Deployment.aspx   Adlan Israilov   Raúl Véjar       10/5/2008 13:10




Developer.aspx    Adlan Israilov   Adlan Israilov   5/20/2009 16:48
Development Process.aspx   Raúl Véjar   Raúl Véjar   9/18/2008 15:40




Disciplines.aspx           Raúl Véjar   Raúl Véjar   10/4/2008 16:20
document owner.aspx          Raúl Véjar       Raúl Véjar        9/4/2009 15:09




document reviewer.aspx       Raúl Véjar       Raúl Véjar        9/4/2009 15:09




Documentation base CM.aspx   Adlan Israilov   Adlan Israilov   5/18/2009 17:19




Documentation Manager.aspx   Raúl Véjar       Raúl Véjar        9/4/2009 15:09




Documentation.aspx           Raúl Véjar       Raúl Véjar        9/4/2009 15:08
Eclipse Shortcuts.aspx   Majid Alfifi   Majid Alfifi   11/19/2008 17:00




Elaboration.aspx         Raúl Véjar     Raúl Véjar      10/4/2008 18:02
Environment.aspx   Raúl Véjar   Raúl Véjar   10/5/2008 13:49
Guidance.aspx   Raúl Véjar   Raúl Véjar   10/5/2008 13:52




Help.aspx       Raúl Véjar   Raúl Véjar   10/5/2008 13:58
Home.aspx                        Raúl Véjar       Raúl Véjar   9/11/2008 23:22




How To Use This Wiki Site.aspx   Adlan Israilov   Raúl Véjar   9/11/2008 23:22
Implementation.aspx   Raúl Véjar   Raúl Véjar   10/5/2008 12:34
Inception.aspx   Raúl Véjar   Raúl Véjar   10/4/2008 17:58
Iteration Management.aspx          Majid Alfifi     Andrew O Mellinger   10/5/2008 16:08




Knowledge Transfer Engineer.aspx   Adlan Israilov   Adlan Israilov        9/25/2008 4:38
Mentor.aspx   Adlan Israilov   Andrew O Mellinger   2/15/2009 10:30
Milestones.aspx   Andrew O Mellinger   Raúl Véjar   10/4/2008 16:59
Model.aspx   Raúl Véjar   Raúl Véjar   10/4/2008 16:52
Overview.aspx   Raúl Véjar   Raúl Véjar   10/5/2008 14:14
Phases.aspx         Raúl Véjar   Raúl Véjar   10/4/2008 16:55




Philosophies.aspx   Raúl Véjar   Raúl Véjar   10/5/2008 14:17
Process definition standard.aspx   Raúl Véjar   Raúl Véjar   9/13/2008 15:56
Process Engineer.aspx   Adlan Israilov   Raúl Véjar   9/18/2008 19:58
Processes.aspx               Raúl Véjar       Raúl Véjar       9/13/2008 15:54




Product CM-Integrator.aspx   Adlan Israilov   Adlan Israilov   5/18/2009 17:36
Project Management.aspx   Raúl Véjar   Raúl Véjar   10/5/2008 13:21
Project Manager.aspx   Adlan Israilov   Raúl Véjar   9/13/2008 22:32
Project Planning.aspx   Andrew O Mellinger   Raúl Véjar   10/9/2008 16:43
Project Tracking.aspx   Raúl Véjar   Andrew O Mellinger   10/5/2008 16:03
Project Vocabulary.aspx   Adlan Israilov   Adlan Israilov   6/26/2009 18:20
Reflections Management.aspx   Majid Alfifi   Majid Alfifi   2/18/2009 18:11




Release Notes.aspx            Raúl Véjar     Raúl Véjar     10/5/2008 19:07
Releases.aspx   Raúl Véjar   Raúl Véjar   10/5/2008 13:25
Requirements Ellicitation.aspx   Andrew O Mellinger   Raúl Véjar   10/16/2008 13:46
Requirements Management.aspx   Mohit Bhonde     Raúl Véjar       10/16/2008 17:05




Requirements Manager.aspx      Adlan Israilov   Adlan Israilov    5/18/2009 19:55
Risk Management.aspx             Andrew O Mellinger   Andrew O Mellinger   9/30/2008 18:38




Role definition standards.aspx   Adlan Israilov       Raúl Véjar           9/13/2008 22:11
Roles.aspx              Adlan Israilov   Raúl Véjar   9/13/2008 22:10




Tailoring guides.aspx   Raúl Véjar       Raúl Véjar   10/5/2008 13:57
Task Tracking.aspx   Andrew O Mellinger   Andrew O Mellinger   3/29/2009 10:15
Team Meeting Management.aspx   Majid Alfifi   Andrew (local)   9/14/2008 16:05
Team Member.aspx      Raúl Véjar       Andrew (local)   9/16/2008 17:56




Technical lead.aspx   Adlan Israilov   Adlan Israilov   5/20/2009 16:29
Test Manager.aspx   Adlan Israilov   Adlan Israilov   5/18/2009 23:00




Test.aspx           Raúl Véjar       Raúl Véjar       10/5/2008 12:55
Tester.aspx       Adlan Israilov   Adlan Israilov   5/20/2009 16:36




Transition.aspx   Raúl Véjar       Raúl Véjar       10/4/2008 18:13
Wiki Content


AUP
Phases
Disciplines
Milestones
Roles
Deliverables
Guidance
Help

The Agile Unified Process (Agile UP) is a streamlined approach to software development based on
IBM's Rational Unified Process (RUP). The Agile UP lifecycle is serial in the large, iterative in the
small, delivering incremental releases over time.




Agile UPDisciplines

Disciplines are performed in an iterative manner, defining the activities which development team
members perform to build, validate, and deliver working software which meets the needs of their
stakeholders. The disciplines are:ModelImplementationTestDeploymentConfiguration
ManagementProject ManagementEnvironment

Agile UPPhases

Phases are performed in a serial manner throughout an Agile UP project. The phases
Objective
The primary purpose of Chief Architect role is to organize and control development of the product's
architecture and maitain its architecture documentation during the whole development lifecycle.


ResponsibilitiesManage development of architecture consistent with architectural drivers
requirementsCoordinate with Project Manager regarding architecture development activities
bydecoupling architecture on separate logical components to be designedreporting status of
architecture developmentacquiring resources for architecture development activitiesControl or track
development of separate architectural components by individuals and consolidate design of those
components into single architecture documentMaintain architecture for the system byupdating
architecture according to architectural drivers changes (priorities of quality attributes or business
drivers and etc.)updating the architectural design as per the detailed design of componentsupdating
and maintaining the architecture document based on the detailed design

Objective
The primary purpose of the Client Liaison is to manage the relationship of the team with the client.
Also, the client Liaison should also be the evangelist for the client perspective. As evangelist they
are not a substitute but responsible for maintaining the visibility of client needs.


ResponsibilitiesManage relationships with the clientsSchedule clients activitiesKeep the clients
informed of team progress, activities, etc.Keep the team informed of client needs, deliverables, etc.Be a
gateway for all team communication to and from the client.Remind the client of deliverable dates in a timely
manner and manage open issues.

Abilities
The central focus of the Liaison is communication and organization. Thus the Client Liaison must
have reasonable communication skills.Acceptable EnglishAccess to communications channels such
as emailReasonable availabilityModerate proficiency with tracking tools such as Excel,
etc.Reasonable people skills
AUP
Phases
Disciplines
Milestones
Roles
Deliverables
Guidance
Help
The goal of this discipline is to manage access to your project work products. This includes not only
tracking work product versions over time but also controlling and managing changes to
them.Workflow

 TipsUse a standard folder/directory structure (seeguidance) for your project work productsIf it's
worth creating it's worth putting under CM controlProvide training in CM because many people will
find the concept strange at firstYour stakeholders should also put their work products under CM
control
 Phase by PhasePhasesActivitiesInceptionSetup the configuration environment. You need to do several
things:Your CM repository will need to be installed if it is not already in place.The appropriate folder/directory
structure, which should follow any existing corporate guidance, needs to be created for the project
team.Project team members will need to be given access to the project folder(s) and any required client
software installed on their workstations.Project team members may also need to be trained in basic CM
concepts and the tools.
Put all work products under CM control. Everyone should put their work under CM control on a regular basis,
checking it in/out as appropriate, resolving update conflicts as needed, and baselining the work products when




Process description
If the team cannot come to consensus on one of the core issues, then mentors will be consulted. The
choice of mentor, advisor, etc. will be based on the nature of the decision.
AUP
Phases
Disciplines
Milestones
Roles
Deliverables
Guidance
Help
The focus of the Construction phase is to develop the system to the point where it is ready for pre-
production testing. In previous phases, the majority of the requirements have been identified and
the architecture for the system has been baselined. Emphasis shifts now to prioritizing and
understanding the requirements (seemodel),model storming a solution, and then
doingimplementation andtest the software. If necessary, early releases of the system are
under deployment, either internally or externally, to obtain user feedback.
To exit the Construction phase your team must pass the Initial Operational Capability (IOC) milestone
(seemilestones). The primary issue here is whether the current version of the system is ready to
move into your pre-production test environment for system and acceptance testing. If the team
passes this milestone the project moves to theTransition phase, otherwise it may be re-directed or
cancelled.
 Work By DisciplineDisciplineMajor ActivitiesModelAnalysis model storming Design model storming
Document critical design decisions ImplementationTest firstBuild continuouslyEvolve the domain logicEvolve
the user interfaceEvolve the data schemaDevelop interfaces to legacy assetsWrite data conversion
scriptsTestTest the softwareEvolve your test model (seedeliverables) DeploymentDevelop (de)installation
Process Description

This process is intended to deal with how the team deals with basic process issues, high level
direction, high level decisions, final document approvals and the like. This is not intended for the
low level details such as coding, task estimation, code reviews, design decisions, etc.


The process is that these sorts of decision require team consensus. That is to say the team as a
whole has to agree. Individual members may not completely agree with every choice, but have to
provide consent. We want every voice to count, and all decisions to be made via compromise. We
are of course cautious about paralysis and will monitor the situation. If we cannot come to an
agreement then the PM is given the responsibility of making a decision by consulting team
members. PM can also use voting once he decides it's taking too long to come to agreement

Roles

All

Artifacts

Input

N/A

Output

N/A
AUP
Phases
Disciplines
Milestones
Roles
Deliverables
Guidance
Help
The Agile UP distinguishes between:Deliverable which you absolutely must produce as a permanent
system work product.Other project work products which you will likely discard because you do not
want tomaintain it over time.Enterprise work products which are maintained within your IT
department and shared across projects.
Fundamental advice for staying agile:Keep your work products as simple and concise as possible.You
need a lot less documentation than you think.Work closely with the people whom you're creating an
work product for so that you produce only what they need.Agile documents arejust barely good
enough for the task at hand.Producing a document is the worst way tocommunicate information,
several people standing around a whiteboard talking is the best.Use simple tools such asplain old
whiteboards (POWs), paper, and Wikis to model and capture documentation.Consider adopting
theopen source templates as a basis from which to create your own. They're probably a lot more
than what you want, but they're a good start.
 Minimum Deliverables
The minimum deliverables for an Agile UP system are described, in priority order, in the following
table:DeliverableDescriptionTipsTemplatesSystemThe working software, hardware, and documentation to be
deployed into production.There is more to your system than just the software that you write. Source CodeThe
program code for your system.Follow common coding guidelines. Regression Test SuiteA collection of test
AUP
Phases
Disciplines
Milestones
Roles
Deliverables
Guidance
Help
The goal of this discipline is to plan for the delivery of the system and to execute the plan to make
the system available to end users.
 Workflow

 TipsWork closely with operations and support staff to determine their needs.Develop and evolve
your installation scripts during theConstruction phase.Have apre-production testing sandbox where
you can validate that your system works before you deploy it into production. See Figure 1.Your
organization may have "blackout periods" when you are not allowed to deploy new software into
production. Common blackout periods are around year end when you need to focus on closing your
financial books and during peak business periods, such as the holiday season for retailers.Have go/no-
go decision points in your deployment process.Be able to "de-install" your system if you run into
problems.Test your (de)installation scripts
Figure 1. Sandboxes.

 Phase by PhasePhasesActivitiesInceptionIdentify the potential release window. For example, you may be
required to deliver your software before the end of the year but after the release of another application that is
planned to go into production at the end of September. Therefore your release window is between October 1st


Objective
The primary purpose of the Developer role is to develop product by copy pasting code.


ResponsibilitiesDevelop code (software)Submit changes to the central code
repositoryFollow development strategy defined by Technical Lead (code "check-in" rules and
etc.)Ensure that code being submitted to the central repository does not have any conflicts and
working properly
General description
Imhotep will be using an adapted UP process to guide the development process. It will
take charasteristics from UP like the use of use cases and the incremental, iterative lifecicle, but will
also include concepts from methodologies like SCRUM to cape with the maintenance part of the
project.


How it will work - What guides the process?
Through theRequirements Ellicitation process, requirements will be divided between new features ,
and new use cases :
Features: These will be small modifications to the already existing program, or new characteristics
evaluated as small improvements to the already in-place design. Features will be given a priority
and put in a stack of available work. On each iteration, a significant use case will be chosen, but
along it, several features might make it into that realease taking into account planning and priority
constraints.Use Cases: These will be new scenarios that will have to be supported and they
represent a significant improvement over existing functionality. These will drive the iterations of the
project like in traditional UP.
The reasons behind the separation are:Not forcing all requirements into use case notation. Since this
is also a maintenance project on an already existing system, many requirements are expected to be
the implementation of small new features or bug fixing in already existings parts of the
product.Helping the planning effort. Given that UP is mostly use case driven in terms of iteration
planning, this will give the flexibility to introduce into iterations the development of features along
with the regular use cases in order to maximize the productivity of the team.
This separation will involve developing an estimation methodology that takes into account both type
of requirements.
Phases

AUP
Phases
Disciplines
Milestones
Roles
Deliverables
Guidance
HelpAgileUP Disciplines
Disciplines are performed in an iterative manner, defining the activities which development team
members perform to build, validate, and deliver working software which meets the needs of their
stakeholders.DisciplineOverviewModelThe goal of this discipline is to understand the business of the
organization, the problem domain being addressed by the project, and to identify a viable solution to address
the problem domain.ImplementationThe goal of this discipline is to transform your model(s) into executable
code and to perform a basic level of testing, in particular unit testing. TestThe goal of this discipline is to
perform an objective evaluation to ensure quality. This includes finding defects, validating that the system
works as designed, and verifying that the requirements are met.DeploymentThe goal of this discipline is to
plan for the delivery of the system and to execute the plan to make the system available to end
users.Configuration ManagementThe goal of this discipline is to manage access to your project work
products. This includes not only tracking work product versions over time but also controlling and managing
changes to them.Project ManagementThe goal of this discipline is to direct the activities that takes place on
Responsabilities:
Collaborates with the documentation manager in developing the plan
Responsible for developing the document




Responsabilities:
Collaborates with the documentation manager in developing the plan
Responsible for contacting owner regarding scheduling document review on every phase



Objective
The primary purpose of Documentation base CM role is to control and organize documentation
process in Sharepoint.


ResponsibilitiesManage team’s documentation base by ensuring that document versions, format
and uploading process are followed as they have been defined.



Responsabilities:
Elaborates plan for developing the document with milestones for Outline, draft and final version
Track progress for document tasks agains plan developed by documenter
Contact clients for feedback request at the outline and final versions.




The overall documentation effort is supervised by theDocumentation Manager. He identifies
individual documents that need to be produced and assigns a pair ofdocument owner/document
reviewer equally responsible for it's delivery.
Thedocumentation manager elaborates the plan for developing the document with particular
milestones for Outline, Draft and Final versions. He is also responsible for tracking progress for
document tasks and reporting problems to the project manager. Finally, he is responsible for contact
clients for feedback request at the Outline and Final versions.
The Document owner collaborates with the documentation manager in developing the plan and is
responsible for developing the document.
The Document reviewer collaborates with the documentation manager in developing the plan and is
responsible for contacting owner regarding scheduling document review on every phase.
Reviews are mandatory for the Outline, Draft and Final versions. The process does not probscribe
having additional milestones in case the documentation effort requires it.
ctrl + shift + R --> "go to Resource"

F4 --> shows hirachy of classes

F3 --> go into (class, method, etc)

alt + <- -> to move between editors
ctrl + shift +F to indent java code




AUP
Phases
Disciplines
Milestones
Roles
Deliverables
Guidance
Help
The primary goal of the Elaboration phase is to prove the architecture for the system (seemodel) to
be developed. The point is to ensure that the team can actually develop a system that satisfies the
requirements, and the best way to do that is to build a end-to-end, working skeleton of the system
called an "architectural prototype". This is actually a poor term for the concept because many
people think that you throw prototypes away. Instead, your goal is to write high-quality, working
software which meets several high risk (from a technical point of view) use cases to show that the
system is technically feasible.
It is important to note that the requirements are not specified completely at this point. They are
detailed only enough to understand architectural risks and to ensure that there is an understanding
of the scope of each requirement so that subsequent planning can be carried out. Architectural risks
are identified and prioritized; the significant ones are addressed during Elaboration. Addressing
architectural risks may take several forms: research into similar system(s), a stand-alone test suite, a
working prototype, etc. In most cases, a working prototype showcasing the architecture is
completed. Your system level architecture should also reflect your overallenterprise architecture.
During Elaboration, the team is also preparing for theConstruction phase. As the team gains a handle
on the architecture of the system, they begin setting up theenvironment for Construction by
AUP
Phases
Disciplines
Milestones
Roles
Deliverables
Guidance
Help
The goal of this discipline is to support the rest of the effort by ensuring that the proper process,
guidance (standards and guidelines), and tools (hardware, software, etc.) are available for the team
as needed.
Workflow

 TipsFocus on developing templates andguidance tailored to the needs of the team.People likely
won't read detailed procedures, but they will ask you for your help.Make it as easy as possible to use
existing corporate licenses of software tools.Be flexible, new project teams may require new types of
software, equipment, or changes to the process.Templates are great, examples of how to use them
are even better.
 Phase by PhasePhasesActivitiesInceptionSet up the working environment. Install workstations as needed
as well as software for those workstations. This will be an ongoing task as people are added to the team over
time.
Identify the project category. Many organizations develop several base versions of their software process, for
example one for small teams, one for legacy system replacement, one for commercial off the shelf (COTS)
system installations, and so on. This gives them a head start at tailoring the AUP (seedeliverables) to meet the
exact needs of each project team because a lot of the common tailoring has already
occurred.ElaborationEvolve the working environment. As your project progresses your understanding of the
AUP
Phases
Disciplines
Milestones
Roles
Deliverables
Guidance
Help
The term guidance is used to represent the standards, guidelines, and procedures which IT
professionals follow in their daily jobs. Our guidance (note: you need to tailor this page, follow
thetailoring guides) pertains to:Coding GuidanceVisit theCoding Guidelines page
 Configuration Management
Your organization should define:A standard/suggested folder/directory structureA version
numbering scheme (this is often driven by your tool)A "how to" guide for CM
 Modeling GuidanceVisit theAgile Modeling Style Guidelines page.You might want to consider
purchasingThe Elements of UML 2.0 Style for anyone who models. It is a pocket-book sized manual
describing style guidelines for all 13 UML 2
 User Interface DevelopmentUser Interface Design Tips, Techniques, and Principles User Interface
Prototyping Tips and Techniques
 Tips for Writing Good GuidanceKeep it concise, simple, and straightforward: nobody is going to read
a 100 page coding standards document, they MIGHT read a 5-page one.Base it on actual, good
practice, not academic theory of the ideal way you want it to be.People need to respect and agree to
it, otherwise they won't follow it.The best people to write guidance are the practitioners who are
expected to follow it.




AUP
Phases
Disciplines
Milestones
Roles
Deliverables
Guidance
Help
To use this product fully you must:Allow blocked content. The menus are written using Javascript,
and that some security products will try to block active content such as this in your browser.Connect
to the Internet. There are many links to external sites, so you'll want to be connected if you want to
read some of the referenced information.
There are various ways to obtain more information regarding Agile UP:Internal process
support.Training. Consider sending your project team members on the two-dayAgile UP
Workshop.Services. Scott Ambler has helped a variety of organizationsadopt the software
process(es) which are best suited for them, and hasmentored and trained project teams in the
various techniques.
Welcome to the process wiki, here you will find process information for the project.

Imhotep is currently using a tailorized version of the AUP (Agile Unified Process) developed by Scott W. Ambler.
The methodology has been expanded to include additional engineering and management techniques designed
to help the project cope with the maintenance and studio parts of the project.

A few links to get you started

Anoverview of the process
A more complete vision ofAUP
An overview of the involveddisciplines orroles

A link to theprocesses page that describes what still needs to be done to fully customize the process.

In case you need help in using the wiki, please read the article onHow To Use This Wiki Site or visit theHelp
section.
How to use this wiki site
   You can use this wiki site to share knowledge, brainstorm ideas, collaborate with your team on a
design, create an instruction guide, build an encyclopedia of knowledge, or just write down daily
information in an easily accessible and modifiable format.


Editing wiki pages
  This wiki site provides what-you-see-is-what-you-get (WYSIWYG) editing. To edit a page, click Edit
at the top of the page. You can insert tables and pictures with the click of a button. When you are
happy with your changes you can click OK to update the page.

Creating links to pages
 You can link to another page in this wiki site by enclosing the name of the page in double brackets
on the edit form. For example, type [[Home]] to create a link to the page named Home and [[How to
use this wiki site]] to create a link to this page.

 To create a link to a page and have the link display different text than the page name, type a pipe
character (|) after the page name, and then type the display text. For example, type [[Home|Home
Page]] to create the link labeled Home Page that points to the page named Home.

 To display double opening or closing brackets without making a link, type a backslash before the
two brackets. For example, \[[ or \]].

Creating pages
 There are two main ways to create a new page in your wiki site:
        Create a forward link to another page and then click on it to create the page:
        This is the recommended way to create a page because it is easier for people to find the
AUP
Phases
Disciplines
Milestones
Roles
Deliverables
Guidance
Help
The goal of this discipline is to transform your model(s) into executable code and to perform a basic
level of testing, in particular unit testing.
 Workflow

 TipsPair programming, where two developers work together at one workstation, can improve the
quality of their work, their learning experience, and their productivity.Test driven development
(TDD), where you write a test and then just enough production code to satisfy that test, works
incredibly well.A sketch can be worth a thousand lines of code. Bymodeling before you code, even if
it's simply aplain old whiteboard (POW) sketch, can prevent significant amounts of rework later
on.Adopt and follow a common set ofcoding guidelines. Refactor your code anddatabase schemas as
you work to keep them of high quality.Have separatedevelopment sandboxes.
 Phase by PhasePhasesActivitiesInceptionTechnical prototyping. You might need to "spike" a small aspect
of a requirement in order to understand it sufficiently, enabling you to estimate (seeproject management) the
effort required. These prototypes are typically small, "throw away" pieces of code.
User interface prototyping. For most stakeholders the user interface (UI) -- the screens, reports, and manuals --
is the system. When the UI is potentially complex, or when your stakeholders want to see what they're going
to get before they buy it, you will want to consider prototyping at least the main screens/pages. The UI
AUP
Phases
Disciplines
Milestones
Roles
Deliverables
Guidance
Help
The primary goals of the Inception phase are to achieve stakeholder consensus regarding the
objectives for the project and to obtain funding. The major activities of the phase include:
Define project scope. This includes defining, at a high level, what the system will do. Equally
important is to define what the system will not do. This establishes the boundaries within which the
team will operate. This usually tales the form of a list of high-level features and/or point form use
cases.
Estimate cost and schedule. At a high level, the schedule and cost for the project are estimated.
General estimates are used for iterations in later phases, more specificity is used for the early
iterations inElaboration. This should not be construed as meaning that the entire project is planned
out at this point. As with all planning, those tasks that are to be completed in the near future are
detailed more accurately and with greater confidence while tasks further down the line are
understood to be estimates with larger margins of error. It has (finally) been recognized by most in
the industry that it is not possible to schedule an entire project at its kick-off with any acceptable
degree of confidence. The best that can be done is to plan for the near term accurately and the
longer term as best as you can.
Define risks. The risks to the project are first defined here. Risk management is important an AUP
project. The list of risks is a living compilation that will change over time as risks are identified,
Process description
At the beginning of each iteration will be planning session.


Roles
Project Manager and all team members.


Artifacts
Input

WBS, up to date tasks, results from tracking process. Reflection from last iteration.

Output

plans following planning process.


Process detail
Before the Meeting:
The team leader prepares an agenda of things to decide in the planning meetingEach member
ensures all iteration tasks are up to date.Each member prepares any notes of the tasks he wants to
work onThe team decides on different tasks to carry on.
Planning Portion: See planning process.



Objective
The primary purpose of Knowledge Transfer Engineer is to investigate Pangea's AETool v1.0 as much
as possible in given amount of time and organize AETool v1.0 learning by Imhotep (researching,
preparing tutorials and etc.)


Responsibilities
Elicit requirements for one of the 3 features suggested by clients and Pangea teamDevelop that
feature till the end of Fall08 semesterCollect feature development data for feature
estimatesOrganize AETool v1.0 learning (technology used, current code base)Gather as much
information as possible about Pangea's artifacts and development of AETool v1.0 in general
Objective
The mentor role is to be used by those who have experience in a discipline who wish to provide this
experience through counseling and guidance rather than teaching and instruction. The mentors
primary task is to be available, supportive and responsive when needed to provide feedback and
answer questions and to be able to demonstrate the skills.


Responsibilities
No specific responsibilities.



Abilities
The central focus of the mentor is communication and organization. Good listening skills and be able
to understand the mentee's needsBe encougragingBe able to challenging the mentee with
reasonable growth tasks.Experience in their domainAbility to demonstrate the skillsAbility to
encourage good behavior and discourage bad behavior while maintaining a good relationship.
AUP
Phases
Disciplines
Milestones
Roles
Deliverables
Guidance
Help
As you can see in Figure 1, there are four milestones in the AUP. At each of these milestones, which
signal the end of the phase, you should consider having a "milestone review" which verifies that your
team has successfully fulfilled the milestone criteria. The four milestones are:Lifecycle Objectives
(LCO)Lifecycle Architecture (LCA)Initial Operating Capacity (IOC)Product Release (PR)

Figure 1. The Phases and Milestones of the AUP.

 Inception Phase Milestone: Lifecycle Objectives (LCO)
At this milestone, the stakeholders assess the state of the project. They must agree on the
following:Scope concurrence. The stakeholders reach agreement as to the scope of the
project.Initial requirements definition. There is agreement that the right set of requirements have
been captured, at a high level, and there is a shared understanding of those requirements.Plan
concurrence. The stakeholders agree with the initial cost and schedule estimates.Risk acceptance.
The risks have been identified, assessed, and acceptable strategies to address them have been
identified.Process acceptance. TheAUP has been initially tailored and agreed to by all
parties.Feasibility. The project makes sense from business, technical, and operational
perspectives.Project plan. Adequate plans are in place for the next phase (Elaboration).Portfolio
compliance. Does the scope of the project fit well into your organization's overall project portfolio?
AUP
Phases
Disciplines
Milestones
Roles
Deliverables
Guidance
HelpWorkflow
TipsYou don't need to create all of the models shown in the workflow diagram above, just the ones
that are appropriate to your situationYou don't need a lot of details during the Inception
andElaboration phases (see Figure 1), so don't invest much time in detailed modeling and
documentation.Model storming (see Figure 1) is done on a just-in-time (JIT) basis to get the details
that you need, typically duringConstruction.Your goal is to create models which arejust barely good
enough for the situation at hand, you can always go back and improve your models later on when
you need more details or the situation changes.Most models are discarded after they're used, asmall
minority are kept (seedeliverables).Most models are done usingsimple tools, oftenplain-old-
whiteboards (POWs), and are discarded when they are no longer needed. This is particularly true of
your "analysis models" because they are rarely needed once the requirement has been implemented
successfully.There is awide range of approaches to modeling: CASE tools are great, but they're not
your only optionTake advantage of enterprise assets such as an enterprise architecture model, any
reference architectures, or enterprise guidance (seedeliverables).Look for opportunities for
reuse,you can reuse more than just code.The wider therange of models that you understand, the
greater the chance that you will be able to apply the right work product for your situation. The UML
is an important part of your modeling toolkit, but it'sonly a subset and frankly it needs to
beextended beyond it's current scope.Alwaysmodel with others. Software development is a lot like
swimming, it's very dangerous to do it alone.Trace your requirements through your models to your
The Agile UP (AUP) is a simplified version of theRational Unified Process (RUP). It describes a simple,
easy to understand approach to developing software using agile techniques and concepts yet still
remaining true to the RUP. I've tried to keep the Agile UP as simple as possible (see
thephilosophies), both in its approach and in its description. The descriptions are simple and to the
point, with links to details (on the web) if you want them. The approach applies agile techniques
includetest driven development (TDD),Agile Model Driven Development (AMDD),agile change
management, anddatabase refactoring to improve your productivity.
Figure 1 depicts the lifecycle of the AUP. The first thing that you'll notice is that the disciplines have
changed. First, the Model discipline encompasses the RUP's Business Modeling, Requirements, and
Analysis & Design disciplines. Model is an important part of the AUP, as you can see, but it doesn't
dominate the process -- you want to stay agile by creating models and documents which arejust
barely good enough. Second, the Configuration and Change Management discipline is now
theConfiguration Management discipline. In agile development your change management activities
are typically part of your requirements management efforts, which is part of theModel discipline.
Figure 1. The Agile UP lifecycle.

Serial in the Large
The serial nature of Agile UP is captured in its four phases :Inception. The goal is to identify the initial
scope of the project, a potential architecture for your system, and to obtain initial project funding
and stakeholder acceptance.Elaboration. The goal is to prove the architecture of the
system.Construction. The goal is to build working software on a regular, incremental basis which
meets the highest-priority needs of your project stakeholders.Transition. The goal is to validate and
deploy your system into your production environment.
 Iterative in the Small
Disciplines are performed in an iterative manner, defining the activities which development team
members perform to build, validate, and deliver working software which meets the needs of their
AUP
Phases
Disciplines
Milestones
Roles
Deliverables
Guidance
Help
The Agile UP is characterized as being "serial in the large", something that you can see via its four
phases which you move through in a serial manner.PhaseGoalsMilestones1. InceptionTo identify the
initial scope of the project, a potential architecture for your system, and to obtain initial project funding and
stakeholder acceptance.Lifecycle Objectives (LCO)2. ElaborationTo prove the architecture of the
system.Lifecycle Architecture (LCA)3. ConstructionTo build working software on a regular, incremental basis
which meets the highest-priority needs of your project stakeholders.Initial Operational Capability (IOC)4.
TransitionTo validate and deploy your system into your production environment.Product Release (PR)

Figure 1. The Phases and Milestones of the AUP.




The Agile UP product is based on the following principles:Your staff knows what they're doing.
People aren't going to read detailed process documentation, but they will want some high-level
guidance and/or training (seehelp) from time to time. This product provides links to many of the
details, if you're interested, but doesn't force them upon you.Simplicity. Everything is described
concisely using a handful of pages, not thousands of them.Agility. The Agile UP conforms to the
values and principles of theAgile Alliance.Focus on high-value activities. The focus is on the
activities which actually count, not every possible thing that could happen to you on a project.Tool
independence. You can use any toolset that you want with the Agile UP. My suggestion is that you
use the tools which are best suited for the job, which are oftensimple tools or even open source
tools.
You'll want to tailor this product to meet your own needs. As you can see, this product is easily
tailorable (seetailoring instructions) via any common HTML editing tool. You don't need to purchase
a special tool, or take a course, to edit these pages.
Process description
In this part a brief description is stated of the problem this process is meant to address.


Roles
All roles that are involved in this process are mentioned here.


Artifacts
Input

Mention of the Artifacts that are needed as input to this process.

Output

Description of the Artifacts that are produced as output of this process.


Process detail
Additional details regarding the process including:Activity outlineInvocation of other
processesPlanning guidelinesExecution guidelines
Objective
The main purpose of Process engineer role folds about two main points:Play a vital role in setting up
processesTo track process and process data to make reports and post mortem activities.
The process engineer needs to indentify with the team all types of processes required. (operational,
managerial, lifecycle/process based) and need to categorize them. The process engineer will
establish all checklists for enacting the processes. It's not responsibility of the process engineer to
instantiate or document a new processes being developed, it should be done by person who needs
that process, process engineer should support introduction, development and tailoring of any
process needed for the project.


Responsibilities
Manage introduction, development and tailoring of team software processes.Keep up-to-date
definitions of all (proposed and already active) processes.Track status of processes by managing
team reflections and notify team about current trends.Ensure that team processes are followed by
the team.



Abilities
The process engineer should have the following abilities,Acceptable EnglishAccess to
communications channels such as emailReasonable availabilityModerate to high proficiency with
tracking tools such as Excel, etc.Know how of process, to know what is enough for the team
Processes define how we intent to do our work, they are defined as a finite sequence of steps that
lead to the fulfillment of some goal . Typically, process descriptions follow someprocess definition
standard, so if you are involved in describing a new process you would probably begin by checing
those out.

There is adevelopment process statement that you might be interested in reading in order to
understand what is being incorporated into the process and why.

Even though Imhotep is based onAUP, the following processes have been defined and still need to
be incorporated inside the defined disciplines:

Project Management discipline:

Project Planning

Project Tracking

Iteration Management

Task Tracking

Team Meeting Management


Requirements Management




Objective
The primary purpose of Product CM/Integrator role is to maintain consistency between components
and the overall product stability.


Responsibilities
 Define and execute the build processManage the creation of main branches, tagging
(product baselines and etc.) Coordinate code merges for consistencyEnsure that code follows the
coding standardPerform integration testing
AbilitiesStrong technical skills
AUP
Phases
Disciplines
Milestones
Roles
Deliverables
Guidance
Help
The goal of this discipline is to direct the activities that takes place on the project. This includes
managing risks, directing people (assigning tasks, tracking progress, etc.), and coordinating with
people and systems outside the scope of the project to be sure that it is delivered on time and within
budget.
Workflow
The project manager is responsable for the success of this efforts, and this processes are executed in
parallel with other project activities:
Project planning
Project tracking
Risk management
Whenever the team has need for a meeting, the following process should be followed:
Team Meeting Management
The following processes should also be taking into consideration for when team decisions are
needed and in case of conflicts:
Conflict Resolution
Decision Making
Typically, an AUP project would follow the additional guidelines regarding Project Management:
Note: Take into consideration that the AUP process was adapted for this project, so the following
Objective
The primary purpose of the Project Manager (PM) is to organize and coordinate the team to ensure
successful completion of the project.


Responsibilities
 Develop and maitain semester planDevelop plan activities for the team members bycoordinating
with technical leader for development activitieshonoring client
commitmentsdelegating(assigning) tasks to the responsible individualTrack progress of all
tasksUpdate progress information for all common tasksMake decisions when the issue goes beyond
the scale of team member's individual responsibilityManage risks and integrate mitigation strategies
into the planPrepare status reports for the team and mentorsResolve conflicts among team
membersSchedule meeting rooms and maintain team's working efficiency by acquiring other
needed by team resources
Abilities
The central focus of the PM is communication and organization. Thus the PM must have reasonable
communication skills.Acceptable EnglishAccess to communications channels such as
emailReasonable availabilityModerate proficiency with tracking tools such as Excel, etc.Reasonable
people skills
Process Description
The purposse of this process is to provide the team with tasks that will drive the project towards
completion. This is not as simple as it sounds since a lot of things have to be take into account for
doing this, including:
Distributing resources as efficiently as possibleMitigating risks by tackling riskiest activities as early as
possibleLeave enough space to accomodate for things not going as plannedMaking sure the critical
path to success is not being blockedManage dependencies among work itemsEffectively
estimatingMake a plan that is easy to change, because it will change.More...
This process will attempt to solve some of this aspects by providing a method that will:
Keep the project moving by forcing work to be allocated to items that move the project's
progressSeparate strategic from tactical planning by providing separation between work items and
tasks planned to acomplish them.Help estimate by providing methods for both new and repeting
tasks.Receive feedback often, by working on an iterative manner.Take into account all stakeholder's
needs by taking into account agreed deadlines and compromises.Allow team members the flexibility
to contribuite to the planning effort by identifying new tasks and planning them on-the-fly.
Roles
Primarily the Project Manager.
Everyone should also contribuite to the planning effort.
Artifacts
Input

Project Goals.
Process documentation.
Program Schedule.
Previous estimations.
Process description
This process describes the basic information for plan tracking.


Roles


Primarily the Project Manager.

Artifacts
Input




Output

The WBS with associated statistics.


Process detail

A WBS is maintained and all tasks are assigned to a WBS entry. Additionally, asks are assigned to an
Proposal evaluation status

Excellent: identified, organized(being planned; complies to the approach identified and captured in
Sharepoint), invariably well-performed and continuously improved by adjusting for the needs of the
team and to the project changes. Quality of the practice is excellent and the practice itself is
essential in the specific areas (team believes that the process is the best choice in the context of
current project).

Satisfactory: identified, organized and performed. Team can live with such performance and quality
of the work, but there is still room for improvement (approach can still be clarified and refined
(adjusted) to improve team's performance or quality of the work)

Needs Improvement: identified, not enough organized and not always performed. Fulfill the criteria
of practice, but should be improved in terms of efficiency and organizational part.

Proposed: identified and proposed, but has not been organized and performed yet.

Finished: successfully or not, but has been used before, fulfilled the criteria of practice, however at
some point finished being used or either tracked, not currently in practice or not worth of tracking.

Abandoned: abandoned due to lack of usefulness or failure to organize and execute.

No visibility: - in case if person does not have visiblity in the process and don't want to affect survey
by his/her answer (it's not used as evaluation status in the list, only for the surveys)

Maintanable code
Process description
There will be a reflection meeting at the end of each iteration.
Roles
Project Manager and all team members.


Artifacts
Input

WBS, up to date tasks, results from tracking process.

Output
Meeting mintues containing the reflections from everybody and evaluations for the set of proposals
discussed.


Process detail
Before the Meeting:Each member ensure all iteration tasks are up to date.Each member prepare any
notes for the reflection session which might include:Good / bad from the processGood / bad from
the project (tasks, etc.)Good / bad from the enviornment

Version 0.9Initial release for Software Development Best Practices in Boston, September 26-29
2005.If your browser displays some sort of "blocked content" warning, the cause would be the
Javascript code for the menu system. Sorry about that.
Version 1.0Released October 16, 2005.Removed Traceability Matrix as an work product after an
interesting discussion on the subject with Craig Larman. Traceability is important, traceability
matrices are needed only to fulfill actual audit requirements (e.g. FDA, SOX, ...).Improved wordings
of several pages based on feedback from Gary Evans.Reworked description of architectural
prototyping in theElaboration phase, theModel discipline, and the Implementation discipline as per
discussion with Craig Larman.Added links from the main lifecycle graphic on theAUP index
andoverview pages to the discipline and phase descriptions.Version 1.1Updated the version number
on the index page (sorry for the confusion)Introduced an Agile UP icon (it's in the main
directory)Replaced the term "work product" with "work product"Fixed the font size in the tables to
be consistentImplementation Discipline page: Added a link toAgile Database Best PracticesModel
Discipline page: Added a links toThe Change Prevention Anti-Pattern,Comparing the Various
Approaches to Modeling in Software Development,Examining the "Big Requirements Up Front
Project teams following the AUP deliver incremental releases over time. In other words, instead of
the "big bang" approach where you deliver software all at once you instead release it into
production in portions (e.g. version 1, then version 2, and so on).
AUP teams typically deliver development releases at the end of each iteration intopre-production
testing and/or demo staging area(s) (see Figure 1). A development release of an application is
something that could potentially be released into production if it were to be put through your pre-
production quality assurance (QA), testing, and deployment processes. Granted, this won’t be true
earliest development releases because you won’t have delivered sufficient functionality to make
deployment worth your while. Furthermore at the beginning of a project you often stub out
interfaces to shared services – such as security, persistence, or even reusable legacy functionality –
so technically you still have some clean up to do before you’re ready to release to production.

Figure 1. Sandboxes.


A good process pattern to adopt is that if you have a new version of working software then you
should consider deploying it at least into the pre-production/demo environments to share it with
others. The sooner it gets into the hands of people outside of your team, the sooner you will start to
get feedback from others.
In Figure 2 you see that the first production release often takes longer to deliver than subsequent
releases; in the first release of a system you likely need to get a lot of the “plumbing” in place and
your team likely hasn’t “gelled” yet enabling them to become efficient at collaboration. The first
production release may take you twelve months to deliver, the second release nine months, and
then other releases are delivered every six months. An early focus on deployment issues not only
enables you to avoid problems it also allows you to take advantage of your experiences during
development. For example, when you are deploying software into your staging area you should take
Requirements ellicitation cover the requirements gathering and analysis workflow.




The process basically consists of the following steps:

1) Define the system's domain model (or glossary) and use cases (including general descriptions,
scenarios, pre and post conditions).

2) Identify new features to be developed and ellaborate an initial version of the feature
description document and paper prototypes to support them.

3) Insert features in the prioritized stack, define priorities and acceptance tests with the customer
and estimate development effort for the features. Features are estimated using comparison
estimation against previously developed features where qualitative comparisons produce estimates
based on those comparissons. If reliable data for comparison is not available, a delphi estimation
method will be implemented for that particular feature.

4) Additional enhancements outside the main use cases and repairs on legacy features, are inserted
in the same prioritized stack, prioritized, estimated, and have their acceptance tests defined just like
any other new feature.

5) Once a feature has been selected to be developed by the schedule, additional effort is put into
analyzing and further refining the feature description document and paper prototypes before going
into implementation. This step is repeated for every feature being shifted into development cycles.

Feature Elaboration Sizing
Requirements managements in AUP is centered around the usage of a prioritized stack where
requirements are taken from and sent to development from the top of the list.




1) New requirements, changes to already implemented requirements, fixes to legacy features and
minor enhancements to already existing features; all this go to the same stack of features where
they are prioritzed and estimated according to therequirements ellicitation process.

2) At the beginning of each iteration, features are "poped" from the prioritized stack according to
the ammount of development effort available in the current cycle

3) Commitment is secured from the engineers implementing the features to ensure that this is
a reasonable commitment for the client.

4) After the feature is developed and the acceptance tests have been cleared, the iteration is
concluded and the cycle begins again for the next iteration for the next features in the prioritized
stack.

5) The process is repeated until the total effort allocated for feature development (main item in the
project) in the project is exhausted.

Developing requirements in this way makes the process much aligned with the changing nature of
the requirements and allows the client to have a much higher degree of control over on the order on
how the system is actually developed.



Objective
The primary purpose of Requirements Manager role is to coordinate all requirements oriented
activities.


ResponsibilitiesManage process of gathering requirements Collaborate the requirements
for the systems bymaintaining requirements (features, use cases, prototypes) in form of documents
plus Sharepoint.maintaining elaboration results for the nice to haves and feature requestscoordinate
with Project manager to delegate detail requirements and design to component ownersCoordinate
with PM for requirements activitiesKeep track of requirements changesUpdate detailed
requirements based on last review sessions or client meetings
Adopted from "Risk Management Plan v1.0 October 17,2004 " from team Voyager of MSD Distance
2004.

Process Description

Risk management is conducted proactively to prevent risks from becoming actual problems during
project execution. Risk management will be an integral component of the overall management
strategy and will be conducted in accordance with the details in the following sections.

This pocess shall provide an overview of the process in which the project management team will
identify, track, validate, and
mitigate risks associated with the Voyager project.

Roles

Project Manager - The project Manager is responsible for maintaining and updating the risk list.
Team Member - All team members are responsible for indentify risks and will be involved in the risk
mitigation planning sessions.

Artifacts

Input

Any source our process.

Output



Objective*
A brief description of the role’s purposes.


Abilities
A list of the abilities and aptitudes required to fulfill this role


Responsibilities*
A full list of role's responsibilities.



* - required sections
AUP
Phases
Disciplines
Milestones
Roles
Deliverables
Guidance
Help

Roles define the responsabilities and abilities that people fulfilling certain tasks should have. Roles
are involved in processes as
the workers of the activities. Roles are defined followingrole definition standards.

Important things to understand:Roles can be held by multiple people.A single person can take on
multiple roles.A role is not a position.You should strive to become ageneralizing specialist who has
one or more specialties.

Role
Description
Status
Source
Chief Architect



Generally Good IdeasLess is more.Understand it first until you change it.Get help tailoring it to
meet your exact needs. That's one of the things thatI (Scott Ambler) do. Yes, this is "consultant
ware".Develop templates, and ideally examples, for the major work products your organization
uses. Put them in the templates folder and link to them from theDeliverables page. Consider using
theopen source templates as a basis from which to start (they're likely a lot more than you need).
 Things You're Not Allowed to DoChange the Agile UP logo.Remove the copyright notice at the
bottom of the pages, or from the diagrams. You can and should add your own copyright notice to
the pages if you update them.
 Easy Things To DoReplace the images/yourLogo.gif file with your corporate logo. This will change
the image at the bottom of each page, although will not update the existing link to my home
page.Update stylesheet/global.css to modify the look and feel of the pages.
 Page by PageHelp page. It should describe how people within your organization can obtain help
from your internal process group (if any). It currently includes my marketing effort to try to get you
to hire me for training and/or SPI consulting services.Guidance page. It should provide links to your
internal standards, guidelines, and procedures. Right now it overviews what type of guidance you
Process description
This process discuss hows tasks are entered, and when they are changed.

The team uses Earned Value Management (EVM) to try to track and understand its progress. The
goal of EVM is to give visibility into how tasks are planned, how much are completed and their
associated costs. To make EVM provide clear results, it is critical that the tasks data reflect what
actually happened with regards to what was planned, when it was completed and how much it
costs. If any of these are set in appriopriately it can skew the data.


Roles
Project Manager and all team members.


Artifacts
All task data is tracked in sharepoint.
Process detail
Task initiation
When a task is initied, enter all the data as appropriate. It is important that all aspects of the data
are entered correctly.

Task Completion
When a task is completed, its actual effort, due date and status must be updated.
Process Description
This document describes the format and process of team meetings. The following are the types of
meeting this process applies for:
Client meetingsPlanning meetingsStatus meetingsReflection meetings
Roles
There will be three roles:FacilitatorScribeTime keeper
It's the responsibility of the team initiator to find people to play the roles identfied above.
Artifacts
Input
The meeting initiator must submit agenda at least 24 hours before the meeting . The format
available in Templates section must be used. for status meetings: the PM will produce meeting
slides containing the individual members status, the action items (near and far) and agenda.

Output

Meeting mintues accroding to the meeting mintues template in the templates section.


Process Detail
Before For status meetings: before the meeting occurs, the PM will:Elicit team member status
including completed and incomplete action itemsElicit items for the agendaDistribute the agenda no
less than 24 hours before the meeting for additionsPrepare the meeting presentation (see artifacts)
for other meetings the meeting initiator will send agenda 24 hours before the meeting.
During
Role Description

Regardless of any other role that is played, every member of the team has the same set of minimal
responsibilities. These are:Turn Timesheets on time.Will perform tasks by their deadline with the
best of their ability.Will report any difficulties that may impact the task schedule to theProject
Manager ASAP.Be respectful and supportive of teammates, mentors and client at all times and seek
conflict resolution if difficult should occur.Will follow allProcesses to the best of their ability.Will
attend all team activities if possible and if can't will notify PM/team before hand.

Adhere to the IEEE code of ethics:
http://www.ieee.org/portal/pages/iportals/aboutus/ethics/code.html
to accept responsibility in making decisions consistent with the safety, health and welfare of
the public, and to disclose promptly factors that might endanger the public or the
environment;
to avoid real or perceived conflicts of interest whenever possible, and to disclose them to
affected parties when they do exist;
to be honest and realistic in stating claims or estimates based on available data;
to reject bribery in all its forms;
to improve the understanding of technology, its appropriate application, and potential
consequences;
to maintain and improve our technical competence and to undertake technological tasks for
others only if qualified by training or experience, or after full disclosure of pertinent
limitations;
to seek, accept, and offer honest criticism of technical work, to acknowledge and correct
errors, and to credit properly the contributions of others;
to treat fairly all persons regardless of such factors as race, religion, gender, disability, age,
or national origin;
to avoid injuring others, their property, reputation, or employment by false or malicious



Objective
The primary purpose of Technical lead role is to support Project Manager in defining product
development strategy and managing implementation part of the project.


Responsibilities
 Work with the Project Manager to define and manage reasonable technical goalsSelecting and
prioritizing technical tasks to meet the goals and dependency needsAssigning individual technical
tasks to available resourcesMediating technical issues between technical stakeholders such as
multiple developersWorking with the Test Manager to support the test effortExtend the Architect's
architecture into the implementationHave final say for resolving technical conflictsCoordinate
technical feature introduction such as integration timesSupport and encourage technical growth of
the team identifying strengths, weakness and working with the Project Manager to set
trainingDefine such things as coding standards
Objective
The primary purpose of Test manager is to manage and organize team's testing effort including
quality assurance part of testing.


ResponsibilitiesMaintain testing planEnsure that testing efforts are ongoing according to
current Quality Assurance planReport testing results and coordinate testing activities with Project
ManagerControls scope of testingEnsure that defects found during integration testing and
acceptance testing are reported to "Mantis" bug tracking system.Manage defects in bug tracking
system



AUP
Phases
Disciplines
Milestones
Roles
Deliverables
Guidance
Help
The goal of this discipline is to perform an objective evaluation to ensure quality. This includes
finding defects, validating that the system works as designed, and verifying that the requirements
are met.
 Workflow

 TipsTest throughout the lifecycle. Figure 1 depicts theFull Lifecycle Object Oriented Testing (FLOOT)
lifecycle diagram.Test driven development (TDD) is aimplementation technique which promotes the
development of high-quality software.You need to automate your test suite to truly support
evolutionary development.Agile practices such aspair programming,modeling with others,
andcollective ownership effectively promote "in progress reviews", resulting inless need for
traditional reviews.If it's worth creating it's worth validating.Acceptance tests
(seedeliverables) should do "double duty" as both requirements and testing work products.
Objective
The primary purpose of Tester role is to perform code testing in order to produce the
product of required level of quality.


Responsibilities
 Write and conduct testsLog outcomes of testingFollow the testing strategy defined by Test manager
in QA plan




AUP
Phases
Disciplines
Milestones
Roles
Deliverables
Guidance
Help
The Transition phase focuses on delivering the system into production. There may be extensivetest
of the system that takes place during this phase, including beta testing. Fine-tuning of the product
takes place here as well as rework (seeimplementation) to address significant defects (your
stakeholders may choose to accept the existence of some known defects in the current release).
The time and effort spent in Transition varies from project to project. Shrink-wrapped software
entails the manufacturing and distribution of software and documentation. Internal systems are
generally simpler to deploy than external systems. High visibility systems may require extensive beta
testing by small groups before release to the larger population. The release of a brand new system
may entail hardware purchase and setup while updating an existing system may entaildata
conversions and extensive coordination with the user community. Every project is different.
To exit the Transition phase your team must pass the Product Release (PR) milestone
(seemilestones). The primary issue here is whether the system can be safely and effectively deployed
into production. If the team passes this milestone the project moves to production. If the project
fails in any area above, the project may be re-directed or cancelled (some projects are such disasters
Item Type   Path




Item        processes/Wiki Pages
Item   processes/Wiki Pages




Item   processes/Wiki Pages
Item   processes/Wiki Pages




Item   processes/Wiki Pages
Item   processes/Wiki Pages
Item   processes/Wiki Pages
Item   processes/Wiki Pages
Item   processes/Wiki Pages




Item   processes/Wiki Pages
Item   processes/Wiki Pages




Item   processes/Wiki Pages
Item   processes/Wiki Pages




Item   processes/Wiki Pages




Item   processes/Wiki Pages




Item   processes/Wiki Pages




Item   processes/Wiki Pages
Item   processes/Wiki Pages




Item   processes/Wiki Pages
Item   processes/Wiki Pages
Item   processes/Wiki Pages




Item   processes/Wiki Pages
Item   processes/Wiki Pages




Item   processes/Wiki Pages
Item   processes/Wiki Pages
Item   processes/Wiki Pages
Item   processes/Wiki Pages




Item   processes/Wiki Pages
Item   processes/Wiki Pages
Item   processes/Wiki Pages
Item   processes/Wiki Pages
Item   processes/Wiki Pages
Item   processes/Wiki Pages




Item   processes/Wiki Pages
Item   processes/Wiki Pages
Item   processes/Wiki Pages
Item   processes/Wiki Pages




Item   processes/Wiki Pages
Item   processes/Wiki Pages
Item   processes/Wiki Pages
Item   processes/Wiki Pages
Item   processes/Wiki Pages
Item   processes/Wiki Pages
Item   processes/Wiki Pages




Item   processes/Wiki Pages
Item   processes/Wiki Pages
Item   processes/Wiki Pages
Item   processes/Wiki Pages




Item   processes/Wiki Pages
Item   processes/Wiki Pages




Item   processes/Wiki Pages
Item   processes/Wiki Pages




Item   processes/Wiki Pages
Item   processes/Wiki Pages
Item   processes/Wiki Pages
Item   processes/Wiki Pages




Item   processes/Wiki Pages
Item   processes/Wiki Pages




Item   processes/Wiki Pages
Item   processes/Wiki Pages




Item   processes/Wiki Pages

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:1
posted:12/3/2011
language:English
pages:120
liamei12345 liamei12345 http://
About