The Essence Kernel

Quick Reference Guide

                                                 

Version 0.3

              

1. Introduction

This Quick Reference Guides provides a brief introduction to the Essence Kernel. It is designed to support the use of the Essence Cards by software development teams and, in particular, the games that can be played with them. For more detailed information see the SEMAT User Guide available from www.semat.org and the full Essence Specification available from www.omg.org.

The use of the kernel and the cards has many benefits for individuals, teams and organizations. These include helping them to:

  • Understand where they are
  • Understand what needs to be addressed
  • Track progress and health
  • Keep projects in balance and avoid catastrophic failures
  • Form good sprint goals and other objectives
  • Form teams
  • Define practice independent checkpoints, milestones and lifecycles.

The Kernel is both simple and incredibly powerful as it 1) captures the key concepts involved in software engineering, 2) allows the progress and health of any software engineering endeavor to be tracked and assessed, and 3) provides the common ground for the definition of software engineering methods and practices. 

1.1 What is Essence?

Essence provides us with a thinking framework that allows teams to understand where they are and acts as a foundation for their way-of-working. At the heart of the Essence approach is the Essence Kernel – a simple state-driven model of software engineering. The Essence Kernel captures the small set of things that are universal to all software engineering endeavors; the things that a team always has to consider or work with when developing software.

The kernel contains seven key elements - Requirements, Software System, Team, Work, Way of Working, Opportunity and Stakeholders. Through states defined on these elements, the kernel provides an intuitive tool for practitioners to reason about the progress and health of their endeavors in a practice-independent way. To distinguish them from the many work products used to describe them these elements are called Alphas. The Alpha view is complemented with two other views 1) a competency-based view of the skill sets the team needs to be able to do them with and 2) an activity focused view of the things that teams always have to do. By populating these views with their practices, teams can quickly assemble, analyze, and share their own way-of-working.

By focusing on the essential things inherent in all software development efforts the Essence Kernel provides a simple definition of the common ground shared by all software development teams regardless of the kind of software being developed, of how the team is organized, of what practices get selected, the size of the system being produced, and the complexity of the problem being addressed.

In summary, the Essence Kernel is a stripped-down, light-weight set of definitions that captures the essence of effective, scalable software engineering in a practice independent way. It gives us a new way to look at the domain of software engineering, a new way to understand the progress and health of our development efforts, and a new way to combine practices into an effective way-of-working. It provides a common reference model all teams can use as they continuously inspect, adapt, and improve their ways of working.

1.2 Presenting the Essence Kernel

The kernel is organized into three discrete areas of concern, each focusing on a specific aspect of software engineering, and each distinguished by the use of a different color. These are:

  • Customer – This area of concern contains everything to do with the actual use and exploitation of the software system to be produced. The area of concern and its card are colored green.
  • Solution – This area of concern contains everything to do the specification and development of the software system. This area of concern and its cards are colored yellow.
  • Endeavor – This area of concern contains everything to do with the team, and the way that they approach their work. This area of concern is colored blue.

Each area of concern contains a small number of:

  • Alphas – representations of the essential things to work with. The Alphas provide descriptions of the kind of things that a team will manage, produce, and use in the process of developing, maintaining and supporting software.
  • Competencies –representations of the key competencies required to do software engineering.
  • Activity Spaces – representations of the essential things to do. The Activity Spaces identify and list generic challenges a team faces when developing, maintaining and supporting software systems, and the kinds of things that the team will do to meet them.

To make the Essence Kernel accessible and easy to use this guide presents the kernel elements in a number of complementary ways. The Alphas and Competencies are presented in overview form and as sets of cards with supporting definitions and checklists. The Activity Spaces are presented purely in overview form.

For example, in this guide, the Alphas are presented using Alpha overview cards, Alpha state cards and full checklists. The cards and checklists used to present the Stakeholder Alpha are shown in Figure 1 below.

Figure 1.  An Alpha overview card, and its accompanying state cards and checklist

Note: The Alpha state cards present an abbreviated view of the Alpha State checklist, useful when using the state cards in a workshop situation. The full checklists show both the abbreviated and full views of the checklist; full checklist items that are viewed as redundant have no abbreviated version and are shown in italics. 

Sets of cards are available from www.semat.org.

2. An Overview of the Alphas

The Alphas do not stand-alone but support each other. The Alphas and their relationships are shown in Figure 2.

Figure 2. The Kernel Alphas

In the customer area of concern the team needs to understand the stakeholders and the opportunity to be addressed:

  1. Stakeholders: The people, groups, or organizations who affect or are affected by a software system.

The stakeholders provide the opportunity and are the source of the requirements and funding for the software system. The team members are also stakeholders.  The stakeholders should be involved throughout the software engineering endeavor to support the team and ensure that an acceptable software system is produced.

  1. Opportunity: The set of circumstances that makes it appropriate to develop or change a software system.

The opportunity articulates the reason for the creation of the new, or changed, software system. It represents the team's shared understanding of the stakeholders' needs, and helps shape the requirements for the new software system by providing justification for its development.

In the solution area of concern the team needs to establish a shared understanding of the requirements, and implement, build, test, deploy and support a software system that fulfills them:

Requirements: What the software system must do to address the opportunity and satisfy the stakeholders.

It is important to discover what is needed from the software system, share this understanding among the stakeholders and the team members, and use it to drive the development and testing of the new system.

  1. Software System: A system made up of software, hardware, and data that provides its primary value by the execution of the software.

The primary product of any software engineering endeavor, a software system can be part of a larger software, hardware or business solution.

In the endeavor area of concern the team and its way-of-working have to be formed, and the work has to be done:

  1. Work: Activity involving mental or physical effort done in order to achieve a result.

In the context of software engineering, work is everything that the team does to meet the goals of producing a software system matching the requirements, and addressing the opportunity, presented by the stakeholders. The work is guided by the practices that make up the team's way-of-working.

  1. Team: A group of people actively engaged in the development, maintenance, delivery or support of a specific software system.

One or more teams plan and perform the work needed to create, update and/or change the software system.

  1. Way-of-Working: The tailored set of practices and tools used by a team to guide and support their work.

The team evolves their way of working alongside their understanding of their mission and their working environment. As their work proceeds they continually reflect on their way of working and adapt it as necessary to their current context.

Each Alpha has a small set of states that are used when assessing progress and health. Associated with each state is a set of pre-defined checklists.  The checklists are available in an abbreviated form, as shown on the cards, and in an expanded form, along with the abbreviated form as shown in tables later in this document.

It should be noted that the states are not just one-way linear progressions.  Each time you reassess a state, if you do not meet all the checklist items, you can go back to a previous state.  You can also iterate through the states multiple times depending on your choice of practices.

The Alphas should not be viewed as a physical partitioning of your endeavor or as just abstract work products.  Rather they represent critical indicators of the things that are most important to monitor and progress.  As an example, team members, while they are part of the Team Alpha, are also stakeholders, and therefore, they can also be part of the Stakeholders Alpha.  In the following sections more detailed information about each of the seven alphas is provided including full state checklists and checklist abbreviations that can also be found on the alpha state cards.  It is recommended that users not use the abbreviations until they have attained a solid understanding of the full checklists.  To aid the use of the Essence framework some redundant checklist items have been suppressed in the abbreviated versions.

2.1 Stakeholders

Stakeholders: The people, groups, or organizations who affect or are affected by a software system.

The stakeholders provide the opportunity, and are the source of the requirements and funding for the software system. They are involved throughout the software engineering endeavor to support the team and ensure that an acceptable software system is produced.

Stakeholders are critical to the success of the software system and the work done to produce it. Their input and feedback help shape the software engineering endeavor and the resulting software system.

Figure 3. Stakeholders: Overview and alpha state cards

 

Table 1. Checklist for Stakeholders 

Recognized: Stakeholders have been identified.

Stakeholder groups identified

All the different groups of stakeholders that are, or will be, affected by the development and operation of the software system are identified.

Key stakeholder groups represented

There is agreement on the stakeholder groups to be represented. At a minimum, the stakeholder groups that fund, use, support, and maintain the system have been considered.

Responsibilities defined

The responsibilities of the stakeholder representatives have been defined. 

Represented: The mechanisms for involving the stakeholders are agreed and the stakeholder representatives have been appointed.

Responsibilities agreed

The stakeholder representatives have agreed to take on their responsibilities.

Representatives authorized

The stakeholder representatives are authorized to carry out their responsibilities.

Collaboration approach agreed

The collaboration approach among the stakeholder representatives has been agreed.

Way-of-working supported & respected The stakeholder representatives support and respect the team's way of working.
Involved: The stakeholder representatives are actively involved in the work and fulfilling their responsibilities.

Representatives assist the team

The stakeholder representatives assist the team in accordance with their responsibilities.

Timely feedback and decisions provided

The stakeholder representatives provide feedback and take part in decision making in a timely manner.

Changes promptly communicated The stakeholder representatives promptly communicate changes that are relevant for their stakeholder groups.
In Agreement: The stakeholder representatives are in agreement.

Minimal expectations agreed

The stakeholder representatives have agreed upon their minimal expectations for the next deployment of the new system.

Rep's happy with their involvement

The stakeholder representatives are happy with their involvement in the work.

Rep's input valued

The stakeholder representatives agree that their input is valued by the team and treated with respect.

Team's input valued & respected

The team members agree that their input is valued by the stakeholder representatives and treated with respect.

Priorities clear & perspectives balanced The stakeholder representatives agree with how their different priorities and perspectives are being balanced to provide a clear direction for the team.
Satisfied for Deployment: The minimal expectations of the stakeholder representatives have been achieved.

Stakeholder feedback provided

The stakeholder representatives provide feedback on the system from their stakeholder group perspective.

System ready for deployment The stakeholder representatives confirm that they agree that the system is ready for deployment.
Satisfied in Use: The system has met or exceeds the minimal stakeholder expectations.

Feedback on system use available

Stakeholders are using the new system and providing feedback on their experiences.

System meets expectations The stakeholders confirm that the new system meets their expectations.

2.2 Opportunity

Opportunity: The set of circumstances that makes it appropriate to develop or change a software system.

The opportunity articulates the reason for the creation of the new, or changed, software system. It represents the team's shared understanding of the stakeholders' needs, and helps shape the requirements for the new software system by providing justification for its development.

It is the opportunity that unites the stakeholders and provides the motivation for producing a new or updated software system. It is by understanding the opportunity that you can identify the value and the desired outcome that the stakeholders hope to realize from the use of the software system, either alone or as part of a broader business or technical solution.

                                     Figure 4. Opportunity: Overview and alpha state cards                       

 

Table 2. Checklist for Opportunity 

Identified: A commercial, social or business opportunity has been identified that could be addressed by a software-based solution.

Idea behind opportunity identified

An idea for a way of improving current ways of working, increasing market share, or applying a new or innovative software system has been identified.

At least one investing stakeholder interested

At least one of the stakeholders wishes to make an investment in better understanding the opportunity and the value associated with addressing it.

Other stakeholders identified

The other stakeholders who share the opportunity have been identified.

Solution Needed: The need for a software-based solution has been confirmed.

Solution identified

The stakeholders in the opportunity and the proposed solution have been identified.

Stakeholders' needs established

The stakeholders' needs that generate the opportunity have been established.

Problems and root causes identified

Any underlying problems and their root causes have been identified.

Need for a solution confirmed

It has been confirmed that a software-based solution is needed.

At least one solution proposed At least one software-based solution has been proposed.
Value Established: The value of a successful solution has been established.

Opportunity value quantified

The value of addressing the opportunity has been quantified either in absolute terms or in returns or savings per time period (e.g., per annum).

Solution impact understood

The impact of the solution on the stakeholders is understood.

System value understood

The value that the software system offers to the stakeholders that fund and use the software system is understood.

Success criteria clear

The success criteria by which the deployment of the software system is to be judged are clear.

Outcomes clear and quantified The desired outcomes required of the solution are clear and quantified.
Viable: It is agreed that a solution can be produced quickly and cheaply enough to successfully address the opportunity.

Solution outlined

A solution has been outlined.

Rep's happy with their involvement

The stakeholder representatives are happy with their involvement in the work.

Solution possible within constraints.

The indications are that the solution can be developed and deployed within constraints.

Risks acceptable & manageable

The risks associated with the solution are acceptable and manageable.

Solution profitable

The indicative (ball-park) costs of the solution are less than the anticipated value of the opportunity.

Reasons to develop solution understood

The reasons for the development of a software-based solution are understood by all members of the team.

  It is clear that the pursuit of the opportunity is viable.
Addressed: A solution has been produced that demonstrably addresses the opportunity.

Opportunity addressed

A usable system that demonstrably addresses the opportunity is available.

Solution worth deploying

The stakeholders agree that the available solution is worth deploying.

Stakeholders satisfied The stakeholders are satisfied that the solution produced addresses the opportunity.
Benefit Accrued: The operational use or sale of the solution is creating tangible benefits.

Solution accrues benefits

The solution has started to accrue benefits for the stakeholders.

ROI acceptable The return-on-investment profile is at least as good as anticipated.

2.3 Requirements

Requirements: What the software system must do to address the opportunity and satisfy the stakeholders.

It is important to discover what is needed from the software system, share this understanding among the stakeholders and the team members, and use it to drive the development and testing of the new system.

The requirements are captured as a set of requirement items. The requirement items can be communicated and recorded in various forms and at various levels of detail. It is important that the overall state of the requirements is understood as well as the state of the individual requirement items. Amongst other things this will help you tell when the system is finished, and judge whether or not an individual requirement item is in scope.

Figure 5. Requirements: Overview and alpha state cards

 

Table 3. Checklist for Requirements

Conceived: The need for a new system has been agreed.

Stakeholders agree system is to be produced

The initial set of stakeholders agrees that a system is to be produced.

Users identified

The stakeholders that will use the new system are identified.

Funding stakeholders identified

The stakeholders that will fund the initial work on the new system are identified.

Opportunity clear There is a clear opportunity for the new system to address.

Bounded: The purpose and theme of the new system are clear.

Development stakeholders identified

The stakeholders involved in developing the new system are identified.

System purpose agreed

The stakeholders agree on the purpose of the new system.

System success clear

It is clear what success is for the new system.

Shared solution understanding exists

The stakeholders have a shared understanding of the extent of the proposed solution.

Requirements' format agreed

The way the requirements will be described is agreed upon.

Requirements management in place

The mechanisms for managing the requirements are in place.

Prioritization scheme clear

The prioritization scheme is clear.

Constraints identified & considered

Constraints are identified and considered.

Assumptions clearly Assumptions are clearly stated.
Coherent: The requirements provide a consistent description of the essential characteristics of the new system.

Requirements shared

The requirements are captured and shared with the team and the stakeholders.

Requirements' origin clear

The origin of the requirements is clear.

Rationale clear

The rationale behind the requirements is clear.

Conflicts addressed

Conflicting requirements are identified and attended to.

Essential characteristics clear

The requirements communicate the essential characteristics of the system to be delivered.

Key usage scenarios explained

The most important usage scenarios for the system can be explained.

Priorities clear

The priority of the requirements is clear.

Impact understood

The impact of implementing the requirements is understood.

Team knows & agrees on what to deliver The team understands what has to be delivered and agrees to deliver it.
Acceptable: The requirements describe a system that is acceptable to the stakeholders.

Acceptable solution described

The stakeholders accept that the requirements describe an acceptable solution.

Change under control

The rate of change to the agreed requirements is relatively low and under control.

Value to be realized clear

The value provided by implementing the requirements is clear.

Clear how opportunity addressed

The parts of the opportunity satisfied by the requirements are clear.

Testable

The requirements are testable.

Addressed: Enough of the requirements have been addressed to satisfy the need for a new system in a way that is acceptable to the stakeholders.

Enough addressed to be acceptable

Enough of the requirements are addressed for the resulting system to be acceptable to the stakeholders.

Requirements and system match

The stakeholders accept the requirements as accurately reflecting what the system does and does not do.

Value realized clear

The set of requirement items implemented provide clear value to the stakeholders.

System worth making operational The system implementing the requirements is accepted by the stakeholders as worth making operational.
Fulfilled: The requirements that have been addressed fully satisfy the need for a new system.

Stakeholders accept requirements

The stakeholders accept the requirements as accurately capturing what they require to fully satisfy the need for a new system.

No hindering requirements There are no outstanding requirement items preventing the system from being accepted as fully satisfying the requirements.
Requirements fully satisfied The system is accepted by the stakeholders as fully satisfying the requirements.

 

2.4 Software System

Software System: A system made up of software, hardware, and data that provides its primary value by the execution of the software.

A software system can be part of a larger software, hardware, business or social solution.

We use the term software system rather than software because software engineering results in more than just a piece of software. Whilst the value may well come from the software, a working software system depends on the combination of software, hardware and data to fulfill the requirements.

Figure 6.  Software System: Overview and alpha state cards

 

Table 4. Checklist for Software System

Architecture Selected: An architecture has been selected that addresses the key technical risks and any applicable organizational constraints.

Architecture selection criteria agreed

The criteria to be used when selecting the architecture have been agreed on.

HW platforms identified

Hardware platforms have been identified.

Technologies selected

Programming languages and technologies to be used have been selected.

System boundary known

System boundary is known.

Decisions on system organization made

Significant decisions about the organization of the system have been made.

Buy, build, reuse decisions made

Buy, build, and reuse decisions have been made.

Key technical risks agreed to Key technical risks agreed to.

Demonstrable: An executable version of the system is available that demonstrates the architecture is fit for purpose and supports testing.

Key architectural characteristics demonstrated

Key architectural characteristics have been demonstrated.

System exercised & performance measured

The system can be exercised and its performance can be measured.

Critical HW configurations demonstrated

Critical hardware configurations have been demonstrated.

Critical interfaces demonstrated

Critical interfaces have been demonstrated.

Integration with environment demonstrated

The integration with other existing systems has been demonstrated

Architecture accepted as fit-for-purpose

The relevant stakeholders agree that the demonstrated architecture is appropriate.

Usable: The system is usable and demonstrates all of the quality characteristics of an operational system.

System can be operated

The system can be operated by stakeholders who use it.

System functionality tested

The functionality provided by the system has been tested.

System performance acceptable

The performance of the system is acceptable to the stakeholders.

Defect levels acceptable

Defect levels are acceptable to the stakeholders.

System fully documented

The system is fully documented.

Release content known

Release content is known.

Added value clear

The added value provided by the system is clear.

Ready: The system (as a whole) has been accepted for deployment in a live environment.

User documentation available

Installation and other user documentation are available.

System accepted as fit-for-purpose

The stakeholder representatives accept the system as fit-for-purpose.

Stakeholders want the system

The stakeholder representatives want to make the system operational.

Operational support in place

Operational support is in place.

Operational: The system is in use in an operational environment.

System available for use

The system has been made available to the stakeholders intended to use it.

System live

At least one example of the system is fully operational.

SLAs supported

The system is fully supported to the agreed service levels.

Retired: The system is no longer supported.

Replaced or discontinued

The system has been replaced or discontinued.

No longer supported

The system is no longer supported.

No authorized users

There are no "official" stakeholders who still use the system.

Updates stopped Updates to the system will no longer be produced.

2.5 Team

Team: A group of people actively engaged in the development, maintenance, delivery or support of a specific software system.

One or more teams plan and perform the work needed to create, update and/or change the software system.

Software engineering is a team sport involving the collaborative application of many different competencies and skills. To achieve high performance, team members should reflect on how well they work together, and relate this to their potential and effectiveness in achieving their mission.

Normally a team consists of several people. Occasionally, however, work may be undertaken by an individual creating software purely for their own use and entertainment. A team requires at least two people, but most of the guidance provided by the Team Alpha can also be used to help single individuals when creating software.

Figure 7. Team: Overview and alpha state cards

 

Table 5. Checklist for Team

Seeded: The team's mission is clear and the know-how needed to grow the team is in place.

Mission defined

The team mission has been defined in terms of the opportunities and outcomes.

Constraints known and defined

Constraints on the team's operation are known.

Growth mechanisms in place

Mechanisms to grow the team are in place.

Composition defined

The composition of the team is defined.

 

Any constraints on where and how the work is carried out are defined.

Responsibilities outlined

The team's responsibilities are outlined.

Required commitment level clear

The level of team commitment is clear.

Required competencies identified

Required competencies are identified.

Size determined

The team size is determined.

Governance rules defined

Governance rules are defined.

Leadership model selected

Leadership model is selected.

Formed: The team has been populated with enough committed people to start the mission.

 

Individual responsibilities are understood.

Enough members recruited

Enough team members have been recruited to enable the work to progress.

Roles understood

Every team member understands how the team is organized and what their individual role is.

How to work understood

All team members understand how to perform their work.

Members introduced

The team members have met (perhaps virtually) and are beginning to get to know each other.

Individual responsibilities understood and  aligned to competencies

The team members understand their responsibilities and how they align with their competencies.

Members accepting work

Team members are accepting work.

External collaborators identified

Any external collaborators (organizations, teams and individuals) are identified.

Communication mechanisms defined

Team communication mechanisms have been defined.

Members commit to team

Each team member commits to working on the team as defined.

Collaborating: The team members are working together as one unit.

Works as one unit

The team is working as one cohesive unit.

Communication open and honest

Communication within the team is open and honest.

Focused on mission

The team is focused on achieving the team mission.

Members know each other

The team members know each other.

Performing: The team is working effectively and efficiently.

Consistently meeting commitments

The team consistently meets its commitments.

Continuously adapting to change

The team continuously adapts to the changing context.

Addresses problems

The team identifies and addresses problems without outside help.

Rework and backtracking minimized

Effective progress is being achieved with minimal avoidable backtracking and reworking.

Waste continuously eliminated

Wasted work, and the potential for wasted work are continuously eliminated.

Adjourned: The team is no longer accountable for carrying out its mission.

Responsibilities fulfilled

The team responsibilities have been handed over or fulfilled.

Members available to other teams

The team members are available for assignment to other teams.

Mission concluded

No further effort is being put in by the team to complete the mission.

 

2.6 Work

Work: Activity involving mental or physical effort done in order to achieve a result.

In the context of software engineering, work is everything that the team does to meet the goals of producing a software system matching the requirements and addressing the opportunity presented by the stakeholders. The work is guided by the practices that make up the team's way-of-working.

The ability of team members to co-ordinate, organize, estimate, complete, and share their work has a profound effect on meeting their commitments and delivering value to their stakeholders. Team members need to understand how to carry out their work, and how to recognize when the work is going well.

                                                 Figure 8. Work: Overview and alpha state cards                    

 

Table 6. Checklist for Work

Initiated: The work has been requested.

Required result clear

The result required of the work being initiated is clear.

Constraints clear

Any constraints on the work's performance are clearly identified.

Funding stakeholders known

The stakeholders that will fund the work are known.

Initiator identified

The initiator of the work is clearly identified.

Accepting stakeholders known

The stakeholders that will accept the results are known.

Source of funding clear

The source of funding is clear.

Priority clear

The priority of the work is clear.

Prepared: All pre-conditions for starting the work have been met.

Commitment made

Commitment is made.

Cost and effort estimated

Cost and effort of the work are estimated.

Resource availability understood

Resource availability is understood

 

Governance policies and procedures are clear.

Risk exposure understood

Risk exposure is understood.

Acceptance criteria established

Acceptance criteria are defined and agreed with client.

Sufficiently broken down to start

The work is broken down sufficiently for productive work to start.

Tasks identified and prioritized

Tasks have been identified and prioritized by the team and stakeholders.

Credible plan in place

A credible plan is in place.

Funding in place

Funding to start the work is in place.

At least one team member ready to start

The team or at least some of the team members are ready to start the work.

Integration points defined

Integration and delivery points are defined.

Started: The work is proceeding.

Development started

Development work has been started.

Progress monitored

Work progress is monitored.

Definition of done in place

The work is being broken down into actionable work items with clear definitions of done.

Tasks being progressed

Team members are accepting and progressing tasks.

Under Control: The work is going well, risks are under control, and productivity levels are sufficient to achieve a satisfactory result.

Tasks being completed

Tasks are being completed.

Unplanned work under control

Unplanned work is under control.

Risks under control

Risks are under control as the impact if they occur and the likelihood of them occurring have been reduced to acceptable levels.

Estimates revised to reflect performance

Estimates are revised to reflect the team's performance.

Progress measured

Measures are available to show progress and velocity.

Re-work under control

Re-work is under control.

Commitments consistently met

Tasks are consistently completed on time and within their estimates.

Concluded: The work to produce the results has been concluded.

Only admin tasks left

The team responsibilities have been handed over or fulfilled.

Results achieved

The team members are available for assignment to other teams.

Resulting system accepted

No further effort is being put in by the team to complete the mission.

Closed: All remaining housekeeping tasks have been completed and the work has been officially closed.

Lessons learned

Lessons learned have been itemized, recorded and discussed.

Metrics available

Metrics have been made available.

Everything archived

Everything has been archived.

Budget reconciled & closed

The budget has been reconciled and closed.

Team released

The team has been released.

No outstanding, uncompleted tasks

There are no outstanding, uncompleted tasks.

 

Document Download

 

Dear User,

to download the documents you have to be registered as a user of this website.

Thanks for your effort!

Your SEMAT Team

 

diana mary quintanilla perez
great contribution
0 (0 Votes)
Posted on 3/30/16 4:56 AM.