STATE OF WASHINGTON 2004_01 - Consulting and... · Web viewEach page claimed to be exempt from disclosure must be clearly identified by the word “confidential ... on Extreme Programming's

STATE OF WASHINGTON

ADMINISTRATIVE OFFICE OF THE COURTS

1206 Quince Street SE

Post Office Box 41170

Olympia, Washington 98504-1170

REQUEST FOR QUALIFICATIONS AND QUOTES (RFQQ)

RFQQ- 2004-01

Consulting and Mentoring on User Interface Design Strategies

TABLE OF CONTENTS

1 PURPOSE...................................................................................4

2 BACKGROUND...........................................................................4

3 SERVICES REQUIRED...............................................................5

4 EXPERIENCE/SKILLS REQUIRED.............................................6

5 RFQQ ADMINISTRATION AND INSTRUCTIONS TO VENDORS7

5.1 RFQQ COORDINATOR......................................................................................................7

5.2 RFQQ SCHEDULE................................................................................................................8

5.3 RFQQ QUESTIONS..............................................................................................................8

5.4 PROPOSAL FORMAT.........................................................................................................8

5.5 PROPOSAL REQUIREMENTS AND CONTENT..................................................................8

5.6 PROPOSAL RESPONSE DATE AND LOCATION................................................................8

5.7 COSTS OF PREPARING PROPOSALS......................................................................9

5.8 PROPOSALS PROPERTY OF THE AOC....................................................................9

5.9 PROPRIETARY INFORMATION/PUBLIC DISCLOSURE.................................................9

5.10 RFQQ AMENDMENTS/CANCELLATION/REISSUE/REOPEN........................................9

5.11 MINOR ADMINISTRATIVE IRREGULARITIES.................................................................9

5.12 INABILITY TO ENTER CONTRACT...........................................................................9

5.13 NO OBLIGATION TO ENTER A CONTRACT....................................................................10

5.14 MULTIPLE CONTRACTS...............................................................................................10

5.15 NON-ENDORSEMENT.....................................................................................................10

5.16 CONTRACT PAYMENT LIMITATIONS..................................................................10

RFQQ-2004-01 Page 2 of 32

6 RFQQ EVALUATION.................................................................10

6.1 AOC EVALUATION TEAM.............................................................................................10

6.2 RFQQ CLARIFICATION..................................................................................................11

6.3 RFQQ INTERVIEWS.........................................................................................................11

6.4 RFQQ SCORING..................................................................................................................11

7 POST EVALUATION.................................................................11

7.1 NOTIFICATION OF SELECTION OF APPARENTLY SUCCESSFUL VENDORS.......11

7.2 DEBRIEFING OF UNSUCCESSFUL VENDORS.................................................................11

7.3 PROTEST PROCEDURES...............................................................................................12

7.4 GENERAL TERMS AND CONDITIONS..................................................................12

APPENDIX A—VENDOR PROPOSAL RESPONSE...........................13

APPENDIX B—AOC’S SOFTWARE DEVELOPMENT PROCESS......15

APPENDIX C—DRAFT OF USER INTERFACE DESIGN PROCESS. 24


1 PURPOSEThe Washington State Administrative Office of the Courts (AOC) is initiating this Request for Qualifications and Quotes (RFQQ) to solicit responses from firms or other independent contractors (vendor) interested in providing consulting and mentoring services in the following areas: (a) Creation of a baseline for an overall user interface design for the Judicial Information System (JIS), (b) Refinement and further development of user interface design standards, (c) Integration of a user interface design process with the AOC’s software development process, (d) Review and refinement of user interface design artifacts, and (e) Creation of a baseline for an architecture for user assistance.The AOC strives to leverage identified industry best practices in these areas. Vendors may bid on one area, combinations of areas, or all five areas. The consulting and mentoring will occur in September and October 2003. Specific dates are to be negotiated with the successful vendor(s).

2 BACKGROUND

The AOC is in the elaboration phase of a multi-year project to migrate existing court case management functionality from legacy mainframe applications and Web applications into a unified, service-oriented, Java 2 Platform Enterprise Edition (J2EE)-based architecture. The software that results from the migration project will be called the Judicial Information System (JIS). The AOC has elected to standardize on a custom instantiation of the Rational Unified Process (RUP) as the agency’s software development process. This process (including standards for workflows, roles, and artifacts) has been defined but not used on an actual project. The AOC has customized the RUP disciplines and artifact templates to align the process with the business objectives and the unique characteristics of the JIS migration project. Existing AOC staff persons are inexperienced with RUP in general and the AOC instantiation in particular. Further information on the AOC software development process is included in Appendix B.As is typical for RUP-based software processes, the AOC software development process employs use cases as the means of evolving and documenting software functional requirements. In particular, the AOC has standardized on the use case form and methodology described by Alistair Cockburn in the book, Writing Effective Use


Cases and further developed in the book Patterns for Effective Use Cases by Steve Adolph and Paul Bramble.Also, as is typical for RUP-based software processes, the AOC software development process employs Unified Modeling Language (UML) diagrams to describe models of the system architecture. As a project evolves, but especially during the elaboration phase, the system designers (not the user interface designers) on the project team are required to perform object design, using UML diagrams and other appropriate means, to describe the design, implementation, and deployment models of the architecture.During the elaboration phase, the AOC has identified multiple risks including several related to user interface design. Successful vendors from this RFQQ will assist the AOC to mitigate the risks tied to user interface design.The AOC recognizes the need for an overall JIS user interface design strategy or baseline design of how the JIS application will look and feel. There is currently no overall JIS user interface design strategy in place. The AOC is interested in baselining a user interface design that gets the most out of rich Java Swing, scores high on usability, etc.Current user interface design standards are focused on a browser-based user interface. Standards for rich Java Swing user interfaces are immature or non-existent. The AOC strives to leverage identified industry best practices like the Java Look and Feel Guidelines. Current application architectural standards and user interface extensions are available at www.courts.wa.gov/procure. The AOC user interface design team has identified a process for conducting user interface design and applying usability engineering principles. However, this user interface design process has not been reconciled with nor integrated into the AOC software development process. A draft of the user interface design process developed by the AOC usability design team is attached as Appendix C to this RFQQ.The AOC has drafted user interface design RUP artifacts that are owned by the user interface designer. These artifacts include a user interface prototype template, usability test plan, usability testing evaluation summary, and training plan. Additionally, the user interface designer contributes to other RUP artifacts such as the supplementary specification document and iteration plan.The AOC also recognizes the need for a comprehensive user assistance strategy to pull together initiatives related to Web self-help, wizards, Help files within applications, etc. In June 2003, the


http://www.courts.wa.gov/procure

AOC purchased knowledge management software from RightNow Technologies as a basis for Web self-help for the AOC’s court clients and public users. AOC is also planning to integrate the RightNow knowledge management solution with Remedy, which is the AOC’s current call generation and tracking system. AOC staff persons presently create Web Help files for JIS and other applications using eHelp Corporation’s RoboHelp. Additional user documentation for court clients is primarily online and accessible by an extranet. The AOC envisions bringing all these user assistance methods, along with other potential methods, together in a comprehensive user assistance strategy. There is currently no strategy in place for an architectural baseline in the area of user assistance.The AOC recognizes that AOC staff persons (fewer than ten) are in need of training and mentoring in the areas identified above. The AOC wishes to incorporate this training and mentoring into any consulting tied to the above four areas.

3 SERVICES REQUIRED

The AOC is issuing this RFQQ to identify vendors with expertise in: (a) overall user interface design (to be used in developing a baseline design of how the JIS application will look and feel), (b) refinement and development of user interface design standards, (c) integration of user interface design processes with custom instantiations of the RUP, (d) development of user interface design RUP artifacts, and (e) development of a baseline for an architecture for comprehensive user assistance. Vendor responsibilities will be to develop strategies to address the areas identified above and to offer some training/mentoring to AOC staff in these same areas.Deliverables are:(a)Overall user interface design strategy and creation of a user

interface design baseline for the JIS AND mentoring on the strategy (estimated to take approximately 160 hours in September 2003).

(b)User interface design standards for rich Java Swing user interfaces AND mentoring on creation of the standards (estimated to take approximately 120 hours in October 2003).

(c) Integration of a user interface design process with the AOC custom instantiation of RUP AND mentoring on the integration activity (estimated to take approximately 160 hours in September 2003).


(d)Maturation and refinement of user interface design RUP artifacts AND mentoring on the refinement of user interface design artifacts (estimated to take approximately 40 hours in September and October 2003).

(e)Creation of a baseline for an architecture for comprehensive user assistance AND mentoring on the strategy (estimated to take approximately 120 hours of time in September and October 2003).

The successful vendor(s) will be responsible for being on site at the AOC in Olympia, Washington, for initial planning sessions on dates to be negotiated with the successful vendor(s) and for additional times as negotiated between the AOC and the successful vendor(s). An AOC project manager will be assigned to these project areas and will exercise oversight of the schedule and expenditure of funds. The AOC will provide vendor team members the appropriate access to AOC staff persons during the project(s).

Responses to this RFQQ should clearly separate proposed approaches, schedules or project plans, pricing for each of the five (5) user interface design strategy areas that is being addressed, and other information per Appendix A. The project plan should include (at a minimum) specific tasks to be undertaken, a time line for those tasks, and what is expected to be achieved by each task.

4 EXPERIENCE/SKILLS REQUIRED

The vendor must propose specific consultants and mentors who have expertise in the following areas:

Overall user interface design strategy and creation of a user interface design baseline (if bidding on deliverable (a) in section 3).

User interface design standards for rich Java Swing user interfaces (if bidding on deliverable (b) in section 3).

Integration of a user interface design process with the AOC custom instantiation of RUP (if bidding on deliverable (c) in section 3).

Maturation and refinement of user interface design RUP artifacts (if bidding on deliverable (d) in section 3).

Creation of a baseline for an architecture for comprehensive user assistance (if bidding on deliverable (e) in section 3).


Training and mentoring on one area, some combination of the areas, or all five areas (if bidding on any deliverable in section 3).

User interface design and software development best practices (if bidding on any deliverable in section 3).

The vendor must provide resumes of specific consultants with the above expertise. If bidding on one area, the resumes should indicate at least three projects in which similar consulting and mentoring was performed. If bidding on multiple areas of the five areas, the vendor may propose different staff for different areas. If bidding on multiple areas of the five areas, the vendor should include resumes for all potential consultants and indicate at least three projects in which similar consulting and mentoring was performed for each of the areas. For all projects indicated, the vendor must provide customer references.

The Vendor should note that substitution at any time of other individuals for the specific consultants proposed in the response will require the explicit written approval of the RFQQ Coordinator.

5 RFQQ ADMINISTRATION AND INSTRUCTIONS TO VENDORS

5.1 RFQQ COORDINATOR

Upon release of this RFQQ, all vendor communications concerning this acquisition must be directed to the RFQQ Coordinator listed below. Unauthorized contact regarding this RFQQ with other state employees may result in disqualification. Any oral communications will be considered unofficial and non-binding on the state. Only written statements issued by the RFQQ Coordinator may be relied on.

Ann E. Sweeney, RFQQ CoordinatorWashington State Administrative Office of the Courts1206 Quince Street SEP. O. Box 41170Olympia, Washington 98504-1170E-mail: [email protected]: (360) 586-2370


mailto:[email protected]

5.2 RFQQ SCHEDULE

RFQQ Released...................................August 8, 2003Questions Submitted to RFQQ Coordinator………... August 13, 2003Responses to Questions Published by RFQQ Coord....August 18, 2003Proposals Due No Later Than 5:00 p.m. Pacific Daylight Time................…August 20, 2003Successful Vendor(s) Announced......August 22, 2003Contract(s) Awarded.........................August 29, 2003Work Commences.................................................TBD

5.3 RFQQ QUESTIONS

Specific questions concerning this RFQQ should be submitted to the RFQQ Coordinator in writing by fax or e-mail no later than the listed date in the RFQQ Schedule. Questions will not be accepted beyond this date. Responses will be posted to the AOC’s Internet site (http://www.courts.wa.gov/procure) no later than the date listed in this RFQQ Schedule.

Oral responses given to any questions are to be considered preliminary and non-binding. Only written responses to questions will be considered official.

5.4 PROPOSAL FORMAT

Vendors must submit their proposals electronically via e-mail to the RFQQ Coordinator per subsection 5.1. Proposals, not including resumes, may not exceed 15 pages per deliverable area. Proposals which exceed 15 pages per deliverable area will be deemed non-responsive and will not be evaluated.

5.5 PROPOSAL REQUIREMENTS AND CONTENT

Vendors must respond to each question/requirement contained in Appendix A, Vendor Proposal Response. Vendors may submit multiple proposals. The skill sets for each individual proposed by the vendor must be clearly identified.

5.6 PROPOSAL RESPONSE DATE AND LOCATION


http://www.courts.wa.gov/procure/home.htm

The vendor’s proposal, in its entirety, must be received by the RFQQ Coordinator in Olympia, Washington, in accordance with the schedule contained in subsection 5.2 above. Late proposals will not be accepted and will be automatically disqualified from further consideration.Responses must be delivered by e-mail. Vendors assume the risk of the method of dispatch chosen. The AOC assumes no responsibility for delays caused by e-mail delivery or any other party. Late proposals will not be accepted nor will additional time be granted to any vendor.

RFQQ-2004-01 Page 10 of 32

5.7 COSTS OF PREPARING PROPOSALSThe AOC will not pay any vendor costs associated with preparing proposals submitted in response to this RFQQ.

5.8 PROPOSALS PROPERTY OF THE AOC

All proposals, accompanying documentation, and other materials submitted in response to this RFQQ shall become the property of the AOC and will not be returned.

5.9 PROPRIETARY INFORMATION/PUBLIC DISCLOSURE

All proposals received shall remain confidential until the evaluation is completed and the vendor is selected and approved. Thereafter proposals shall be deemed public records as defined in RCW 42.17.250 to .340.Any information contained in the proposal that is considered proprietary and exempt from disclosure under the provisions of RCW 42.17.250 to .340 by the vendor must be clearly designated. The page must be identified as well as the particular exception from disclosure upon which the vendor is making the claim. Each page claimed to be exempt from disclosure must be clearly identified by the word “confidential” printed in the lower right hand corner of the page. Marking of the entire proposal as proprietary will be neither accepted nor honored. If a request is made to view or obtain a copy of a vendor’s proposal, the AOC will comply with applicable public disclosure requirements. If any information in the proposal is marked as proprietary, such information will not be made available until the affected vendor has been given an opportunity to seek an injunction or restraining order against the requested disclosure.

5.10 RFQQ AMENDMENTS/CANCELLATION/REISSUE/REOPEN

The AOC reserves the right to change the RFQQ Schedule or issue amendments to this RFQQ at any time. The AOC also reserves the right to cancel or reissue this RFQQ.

5.11 MINOR ADMINISTRATIVE IRREGULARITIES

The AOC reserves the right to waive minor administrative irregularities contained in any response.

RFQQ-2004-01 Page 11 of 32

5.12 INABILITY TO ENTER CONTRACT

The AOC reserves the right to eliminate from further consideration any vendor that the AOC, because of legal or other considerations, is unable to contract with at the time responses are due in accordance with the schedule contained in subsection 5.2 above.

5.13 NO OBLIGATION TO ENTER A CONTRACT

The release of this RFQQ does not compel the AOC to enter any contract.

The AOC reserves the right to refrain from contracting with any vendor that has responded to this RFQQ whether or not the vendor’s proposal has been evaluated and whether or not the vendor has been determined to be qualified. Exercise of this reserved right does not affect the AOC’s right to contract with any other vendor.

The AOC reserves the right to request an interview with any vendor who is a prospective contractor prior to entering a contract with that vendor. If a vendor declines the request for an interview for any reason, the vendor will be eliminated from further consideration.

5.14 MULTIPLE CONTRACTS

The AOC reserves the right to enter contracts with more than one vendor as a result of this RFQQ.

5.15 NON-ENDORSEMENT

The selection of a vendor pursuant to this RFQQ does not constitute an endorsement of the vendor’s services. The vendor agrees to make no reference to the AOC in any literature, promotional material, brochures, sales presentations, or the like without the express written consent of the AOC.

5.16 CONTRACT PAYMENT LIMITATIONS

The Washington State Constitution provides that the state of Washington shall make no advanced payment for goods or services. Therefore, the vendor should anticipate payment at the end rather than the beginning of the invoice period in

RFQQ-2004-01 Page 12 of 32

which it submits any services for which a payment is due. Invoices should be submitted no more often than monthly.

6 RFQQ EVALUATION

6.1 AOC EVALUATION TEAM

An AOC Evaluation Team (Team) of at least three (3) persons will evaluate the responses to this RFQQ. In the evaluation, the Team will review the qualifications of the individuals proposed by the vendor to provide the required services, references of the vendor and individuals, and the cost quoted. The Team may also consider past contract performance and check references beyond those listed in the vendor’s proposal.

RFQQ-2004-01 Page 13 of 32

6.2 RFQQ CLARIFICATION

As part of the evaluation process, at the discretion of the Team, vendors may be asked to clarify specific points in their proposal. However, under no circumstances will the vendor be allowed to make changes to the proposal.

6.3 RFQQ INTERVIEWS

The Team may request an interview with the vendor that scores the highest in each of the areas. The Team may also interview the individual proposed by that vendor. If a vendor or individual declines the request for an interview for any reason, the vendor will be eliminated from further consideration.

6.4 RFQQ SCORING

Each of the five areas reviewed will be evaluated on a 50 point scale. All deliverables and individuals proposed by the vendor will be considered within each of the five areas and awarded points as follows:

Evidence from resumes of proposed individuals of experience in consulting and mentoring on one of the five areas. Ten (10) points.

Evidence from resumes of proposed individuals that primary duties for the past year have been in the area for which the vendor is bidding. Ten (10) points.

Proposed approach for each area deliverable. Ten (10) points.

Proposed schedule or project plan for each area deliverable. Ten (10) points.

Price competitiveness. Ten (10) points.

7 POST EVALUATION

7.1 NOTIFICATION OF SELECTION OF APPARENTLY SUCCESSFUL VENDORS

RFQQ-2004-01 Page 14 of 32

Vendors whose responses have not been selected for further negotiations or award will be notified via fax or e-mail.

7.2 DEBRIEFING OF UNSUCCESSFUL VENDORS

Vendors who submitted responses that were not selected will be given the opportunity for a debriefing conference. A request for a debriefing conference must be received by the RFQQ Coordinator within three (3) business days after the notification to unsuccessful vendors is faxed or e-mailed to vendors. The debriefing must be held within three (3) business days of the request.

Discussion will be limited to critique of the requesting vendor’s response. Comparisons between responses or evaluations of other responses will not be allowed. Debriefing conferences may be conducted in person or on the telephone, at the discretion of the RFQQ Coordinator, and will be scheduled for a maximum of one (1) hour.

7.3 PROTEST PROCEDURES

Vendors submitting a protest to this procurement shall follow the procedures described herein. Protests of vendors that do not follow these procedures shall not be considered. This protest procedure constitutes the sole administrative remedy available to the vendor under this procurement.

All protests must be in writing and signed by the protesting party or an authorized agent. The protest must state all facts and arguments on which the protesting party is relying. All protests shall be addressed to the RFQQ Coordinator.

Only protests stipulating an issue of fact concerning a matter of bias, discrimination, or a conflict of interest, or non-compliance with procedures described in the procurement document shall be considered. Protests not based on procedural matters will not be considered.In the event a protest may affect the interest of any other vendor, such vendor(s) will be given an opportunity to submit their views and any relevant information on the protest to the RFQQ Coordinator.

Upon receipt of a protest, a protest review will be held by the AOC to review the procurement process utilized. This is not

RFQQ-2004-01 Page 15 of 32

a review of responses submitted or the evaluation scores received. The review is to ensure that procedures described in the procurement document were followed, all requirements were met, and all vendors were treated equally and fairly.

Protests shall not be accepted prior to selection of the apparent successful vendor. Protests must be received within five (5) business days from the date of the notification of the apparent successful vendor. The AOC Administrator or assigned delegate will then consider all the information available to her/him and render a written decision within five (5) business days of receipt of the protest, unless additional time is required. If additional time is required, the protesting party will be notified of the delay.

7.4 GENERAL TERMS AND CONDITIONS

The vendor selected will be expected to enter into a contract with the AOC which is substantially the same as the contract listed as a separate attachment with this RFQQ, including the AOC’s General Terms and Conditions. In no event is a vendor to submit its own standard contract terms and conditions as a response to this RFQQ.

RFQQ-2004-01 Page 16 of 32

APPENDIX A

STATE OF WASHINGTON




RFQQ-2004-01

APPENDIX A—VENDOR PROPOSAL RESPONSE

Vendors must provide the information below. Failure to provide any of the information below will result in disqualification of the vendor’s proposal.

1. Vendor name.

2. Contact name, address, telephone number, e-mail address, and fax number of vendor.

3. Describe the legal status of vendor, e.g., corporation, sole proprietor, etc.

4. Provide the vendor’s Federal Tax Identification Number (TIN) (or Social Security Number [SSN]) and vendor’s Uniform Business Identifier (UBI) number (if applicable). Information about the UBI can be obtained by calling the Washington State Department of Licensing, or by visiting its Web site at: http://www.wa.gov/dol (click the link for the Master Business Application).

5. Provide a statement that the price quoted in the attached response constitutes a firm offer valid for sixty (60) days following receipt and that the AOC may accept any time within the sixty (60)-day period.

6. Provide a statement that no assistance in preparing the response was received from any current or former employee of the state of Washington whose duties relate(d) to this RFQQ, unless such assistance was provided by the state employee in his or her official public capacity and that neither such employee nor any member of his or her immediate family has any financial interest in the outcome of this RFQQ.

7. State if the vendor or any employee of the vendor is related by blood or marriage to an AOC employee or resides with an AOC employee. If there are such relationships, list the names and relationships of said

RFQQ-2004-01 Page 17 of 32

http://www.wa.gov/dol

APPENDIX A

parties. Include the position and responsibilities within the vendor’s organization of such vendor employees.

8. State whether any of the individuals proposed is a current state employee or a former state employee during the past two (2) years. State the employing state agency, individual’s title at that state agency, and termination date.

9. If the vendor has had a contract terminated for cause during the past five (5) years, describe all such incidents, including the other parties’ name, address, and telephone number. Present the vendor’s position on the matter. Termination for cause is defined as notice to stop performance or delivery due to the vendor’s non-performance or poor performance, and the issue was either: (a) not litigated; or (b) litigated and such litigation determined the vendor to be in cause. If the vendor has had no such terminations for cause in the past five (5) years, so state. Poor contract performance may cause the vendor to be eliminated from consideration. FAILURE TO DISCLOSE will result in disqualification of the vendor and, if applicable, may be grounds for termination of any contract entered with the vendor.

10. Resumes of individuals proposed by vendor for each of the five (5) user interface design areas.

11. Description of vendor’s proposal as to which individuals will be participating in each of the five (5) areas.

12. Proposed approach for each area deliverable.

13. Proposed schedule or project plan for each area deliverable.

14. Name and contact information for at least two (2) references each for each of the five (5) areas. If one or more areas were done for the same customer, then that customer can serve as a reference for more than one (1) area.

15. Separate pricing for fulfilling vendor responsibilities for each area deliverable. Include travel expenses in the overall quote for each area deliverable rather than including an itemized line item for travel in the quote.

RFQQ-2004-01 Page 18 of 32

APPENDIX B

STATE OF WASHINGTON




RFQQ-2004-01

APPENDIX B—AOC’S SOFTWARE DEVELOPMENT PROCESS

Purpose

The purpose of this document is to provide a short, high-level overview of the AOC Software Development Process (SDP).

Relationship to the Rational Unified Process (RUP)

Isn't the AOC SDP just RUP? And so, why do we need this document...shouldn't we simply be reading the RUP documentation?

These are fair questions. And the answer is, yes and no. The Rational Unified Process, in all of its comprehensiveness, constitutes a large body of information. Consequently, it is easy to miss the forest for the trees. In addition, it is important to remember that the RUP is a process framework, not a process in itself. This means that RUP is intended to be customized based on the culture and needs of the organization using it. At the AOC, we have respected this intent by thinking carefully about the guidance offered by RUP and have chosen to adopt those aspects of RUP that make sense for us. The resulting customized process is our "instantiation" of RUP, called the AOC SDP. The purpose of this page is to present a high-level overview of the SDP, and to point to relevant sections of the RUP documentation as appropriate.

This document is merely an overview of the process and a description of some of the principles. The official documentation of the AOC SDP is in the Development Case artifact.

This document also is not intended to replace the extensive available literature on RUP principles. The RUP documentation, which AOC licensed from Rational, is a good place to start in understanding the details of the process. Also, The Unified Software Development Process, by Booch, Rumbaugh, and Jacobson, is a comprehensive treatment of the theory

RFQQ-2004-01 Page 19 of 32

APPENDIX B

behind RUP. Phillipe Kruchten's book The Rational Unified Process: An Introduction is in a similar vein, but shorter and more accessible.

The motivation behind this document is to condense the substantial RUP literature down to a short overview, so that AOC ISD staff and key JIS stakeholders can get an idea of what the process is without undertaking months of study. It is expected that readers will refer to the literature for more detail on areas that interest them or are relevant to their roles.

The AOC SDP in One Sentence

The SDP really boils down to this:

People playing roles deliver business value by creating artifacts in workflows across phases.

In the rest of this document, we will explore what is meant in the SDP by roles, artifacts, workflows, and phases. Before doing so, however, we will look at a few principles that are at the core of the RUP, and therefore of the SDP as well.

Principles of the AOC SDP

There are three main principles that govern the RUP and the AOC SDP:

The process is iterative and incremental The process is use-case driven The process is architecture-centric

In the following sections, we will examine each of these principles briefly. For a more detailed exploration of these principles, the best reference is The Unified Software Development Process, by Booch, Rumbaugh, and Jacobson.

An Iterative and Incremental Process

Being iterative and incremental means primarily that a software development project is broken down into lots of little projects, with lots of intermediate milestones, and lots of opportunity to incorporate learning into the project plan.

It may be easiest to understand the concept of iterative-and-incremental process in terms of what it is not: the traditional waterfall approach. In the waterfall, the "phases" of a project were associated with the major workflows in a linear, one-way fashion. A project would do a substantial

RFQQ-2004-01 Page 20 of 32

APPENDIX B

period of Requirements, which would flow into a substantial period of analysis and design, which would flow into implementation, and finally test followed by deployment. On a waterfall project, it is unacceptable to go "backwards," for instance to return to the requirements workflow once analysis and design has begun. The pressure is on in each phase to "get everything correct," so that the phase's work never has to be revisited.

The waterfall approach was first devised in the 1960s on defense and space projects, in an era when systems were much simpler than they are today, and the power of software development technologies was much less than it is now. Over the past decade or so, the industry has learned that more often than not, the waterfall approach leads to sub-optimal results, especially on projects attempting to develop software for the automation and support of business processes.

An iterative-and-incremental approach respects some of the key insights from the waterfall approach, by retaining the importance of the distinct workflows: requirements, analysis/design, implementation, and test. On an iterative-and-incremental project, we still do all of these things. The difference is, we break the larger project down into many "mini projects," called iterations, and follow the waterfall process during each iteration. Each iteration, which should last no more than three weeks but remain fixed in duration throughout the project, will follow the workflows in the traditional order, and produce a concrete deliverable at the end consisting of a set of artifacts. This deliverable is called an increment, because it is an incremental step towards the final project deliverable.

One of the initial problems solved by an iterative-and-incremental process was the difficulty and risk associated with waiting until the end of a project to build the executable software artifacts. Often on waterfall projects, many months would go by before a team attempted to build an executable and test it. As system complexity increased, this sort of "big bang" integration style would invariably cause delays in delivery and inadequate testing. On an iterative-and-incremental project, the increment is built and fully tested at the end of every three-week iteration, or more often as project needs dictate. For the JIS Migration project at the AOC, the standard will be to perform continuous integration, which means fully integrating, building, and testing the software every day.

It is important to note that the basic iterative-and-incremental strategy can be nested, so that a major, multi-year project like the JIS Migration can be broken down into large iterations, the purpose of which is to deliver a major chunk of functionality or functionality for a major subset of the user population. These large iterations may span several months, and so are still too large to manage as a whole unit. So, we break each large iteration down

RFQQ-2004-01 Page 21 of 32

APPENDIX B

into the smaller iterations called for by RUP, each of which exercises the full set of workflows and lasts up to three weeks.

It is also important to note that the emphasis of certain workflows in an iteration will depend on the phase of the project in which the iteration occurs. As we will see later in this document, there are four phases in a RUP project: inception, elaboration, construction, and transition. As we will see, during the elaboration phase (for instance) the requirements, analysis, and design workflows will carry heavier emphasis than the implementation workflow, though all workflows will be present to a certain extent.

For more information on iterative-and-incremental development, see the RUP Iteration Concept Page and Chapter 5 in The Unified Software Development Process, by Booch, Rumbaugh, and Jacobson. Also, Surviving Object-Oriented Projects by Alistair Cockburn offers a useful perspective on iterative development.

A Use Case Driven Process

Software development projects happen because someone decides to invest some resources (mainly money) in building new software or altering existing software to accomplish some sort of business objective. Like all investing situations, the investor has a right to a certain level of comfort that the resources invested are being spent wisely, and in pursuit of the business objective established at the outset of the project.

The notion that a software development project is an investment of resources in pursuit of some business objective is at the core of the RUP. Consequently, the RUP incorporates use cases as a means of identifying the behavioral requirements of the software in a way that ties the requirements to business value.

A use case is a structured body of text that documents a behavioral requirement in three important ways:

1. It identifies who or what in the business derives value from the software behaving in this way (the who or what is called an actor)

2. It identifies the goal that the actor has with respect to the system (i.e., the use case is written with the understanding of how the user expects the system to deliver the value)

3. It identifies a sequence of interactions between the actor and the system, so it is clear exactly how the system and actor interact in achieving the actor's goal

RFQQ-2004-01 Page 22 of 32

APPENDIX B

Note the emphasis on business value in this definition, and that the requirement explicitly identifies where the business value of the behavior acrues in the organization.

In RUP and the AOC SDP, use cases drive the whole process, which allows us to tie explicitly everything we do back to business value that is recognizable to the business. Use cases drive design, which drives implementation; use cases are used to build test cases to confirm that the software behaves correctly. Use cases are used in project management, to identify the purpose of an iteration or release.

For more information on use case-driven process, see chapter 3 in The Unified Software Development Process, by Booch, Rumbaugh, and Jacobson, and the RUP Use Case Arifact Page. The best source on use case writing is Alistair Cockburn's book, Writing Effective Use Cases.

An Architecture-Centric Process

The RUP defines architecture-centric as "meaning that a system's architecture is used as a primary artifact for conceptualizing, constructing, managing, and evolving the system under development."

Before attempting to digest that, it would be helpful to understand what architecture is. RUP defines architecture as the set of significant decisions about:

the organization of a software system the selection of structural elements and their interfaces by which the

system is composed, together with the behavior as specified in the collaboration among those elements

the composition of these elements into progressively larger subsystems

the architectural style that guides the software development organization, these elements and their interfaces, their collaboration, and their composition

Architecture also represents decisions about the context in which the software will reside, including: usage, functionality, performance, resilience, reuse, comprehensibility, economic and technological constraints/tradeoffs, and aesthetics. Architecture looks outward from the software at its fit within two contexts: the operational context, as represented by the users who use the software in their jobs, and the developmental context, as represented by the organization that builds it.

RFQQ-2004-01 Page 23 of 32

APPENDIX B

Architecture is part of the design of the software, but not all of the design. It is the design of the "most significant" or "major" elements of the software; it is the design of those elements that have a pervasive effect on the qualities of the system--namely, evolvability and performance.

Less formally, architecture can be viewed as that which remains when you remove detail from a software system, yet still have enough to understand the essence of how the system works and is structured. It is an essential understanding of the system, without a lot of detail. In the Extreme Programming methodology (which can be viewed as a particular subclass of RUP), architecture is viewed as a metaphor, in that it abstracts the essence of the system while removing detail to focus the audience on what is important for understanding the system's structure.

So, what does an architecture look like? In RUP, architecture takes two forms: a description, and an executable architectural prototype, both of which are created in the elaboration phase as part of the architectural baseline. The description is structured into views, which are simplified descriptions or abstractions of the software system from a particular vantage point. In RUP and in the AOC SDP, there are five views: the logical view (which addresses the functional requirements of the system by abstracting the design model), the implementation view (which addresses the static organization of the software in its development environment, including configuration management), the process view (which addresses concurrent processes at runtime and their interactions), the deployment view (which addresses the mapping of components to physical computing nodes at runtime), and the use case view (which addresses the functional requirements of the system by abstracting the requirements model, and ties the other views together.) This idea of four views joined logically together by the use case view is called the "4+1" model of architecture and is a foundation of RUP.

It is common to think that views and models are really the same thing, but in fact they are different. A model is a description of the software designed to illuminate particular facets or qualities. A model is intended to tell a story about the entire system. An architectural view, on the other hand, selects only those features in a model that are architecturally significant, or important for understanding the system. As such, a view is like a "slice through" a model, or an abstraction of the model to cover just those significant elements.

Getting back to the purpose of this section now: what does it mean to have an architecture-centric process? The answer is that such a process must do two things. First, it must seek to establish an architectural baseline before construction begins. That is, we develop an understanding of the essential

RFQQ-2004-01 Page 24 of 32

APPENDIX B

form and structure of the system before we build it. And second, we recognize that the software we build via the process must remain consonant with the architecture. Since in an iterative and incremental process, we recognize that we will learn new things about the software throughout the project, this means that we must also recognize that the software architecture will evolve as the project moves forward. If done correctly, there will not be significant changes to the baseline (or else it wasn't truly a baseline) and therefore the essential structure of the system will not change throughout the project. But at the same time the architecture will grow or bend to accommodate what is learned as time passes, so that the documented architecture always remains a true description of the system's essence.

RFQQ-2004-01 Page 25 of 32

APPENDIX B

Phases in the AOC SDP

In RUP and the AOC SDP, there are four phases through which a software system progresses from the time it is first conceived in the mind of a stakeholder until it is delivered into production use. These four phases are: inception, elaboration, construction, and transition. The RUP Documentation offers a more detailed discussion of each phase. The Unified Software Development Process, by Booch, Rumbaugh, and Jacobson, offers the most comprehensive treatment of the purpose and content of each phase.

In reading what follows in this section, it is important to remember that the four phases apply to the JIS Migration project overall, as well as to the larger, "macro," several-month iterations or "projects" that will constitute the migration project construction phase. That is, during the construction phase of the JIS Migration project, a number of sub-projects will be run, and each of these sub-projects will go through the four phases in pursuit of their project deliverables.

Also note that all phases on individual projects will be run iteratively. Typically the inception and transition phases will have only one iteration. Elaboration and construction will typically have several iterations. Iterations should never be longer than three weeks; two weeks is preferred.

The Inception Phase

The goal of the inception phase is to establish the business case, that is, the case for going forward with the project. To achieve this goal, we do the following:

1. Decide what is in scope and out of scope for the system. This involves identifying the system boundary and interfaces to related systems outside the boundary.

2. Describe a candidate architecture, at a very high level, to attain a level of comfort that a stable architecture for the system is feasible

3. Identify critical risks (those that could sink the project) and mitigation strategies

This information forms a basis for the start of a business case, including a feature list, vision statement, business context, and success criteria/expectations. With a business case in hand, the stakeholders (or at least that portion of the stakeholder group responsible for funding the project) can make a "go/no-go" decision on the project.

RFQQ-2004-01 Page 26 of 32

APPENDIX B

The Elaboration Phase

The main goal of the elaboration phase is to develop a stable architecture for the system. As noted above, architecture consists of five views, one of which is the use case view that ties the other four together. So, an important product of the elaboration phase is a mature set of use cases, with a focus on "full coverage" of the use cases if not detailed depth in their descriptions. With a fairly mature use case view in place, it is possible to create a "baseline" architectural description involving the other four views. These five views are organized together into a software architecture description, which is one of the most important artifacts on a RUP project.

In addition to the architecture description document, the elaboration phase produces one or more executable prototypes of the architecture, that prove the most significant and/or riskiest parts of the architecture can actually be implemented.

The Construction Phase

The goal of the construction phase is to reach a state of operational capability. That is, the construction phase actually builds the system that real users will actually use.

It is common to think that the construction phase is all implementation, or "coding." But in actuality, when construction begins, it is typical for more than half of the analysis and design work on the project to remain. This is why an iterative approach is so important: because we don't pretend to be able to "pin down" the design before writing any code. Instead, we let the design evolve as our understanding of the system improves.

It is also common to assume that testing happens after the construction phase, or at least at the end of it. To the contrary, in RUP and the AOC SDP, testing begins at the same time construction begins; the software is subjected to both unit testing and functional testing throughout the phase.

One of the riskiest activities in construction at the outset is building the executable artifacts of the system. In the past, it has been common to put off integration of system components until near the end of the project, when the difficulty of the task and the risks it revealed would generally cause substantial delays in transition, and substantial reduction in the quality of the software. On RUP projects and in the AOC SDP, the best practice of continuous integration is followed. Continuous integration dictates that the entire set of executable artifacts in the system is built once per day, in an automated, unattended manner, and once built, the artifacts are fully tested

RFQQ-2004-01 Page 27 of 32

APPENDIX B

by automated suites of unit and functional tests. This eliminates the risks of "big bang" integrations and reserving testing for the end of a project.

The Transition Phase

The goal of the transition phase is simple: prepare the system for release into a production environment, and into the hands of real users. Typically this involves some type of user acceptance or "beta" test, in which a carefully selected user subset (chosen for their patience and understanding!) is given an opportunity to use the software, and then to offer feedback about its readiness for general release. The transition phase also involves preparation of user manuals and training materials.

Disciplines in the AOC SDP

This section describes the disciplines in the AOC SDP. A discipline in RUP is a set of activities that together produce some observable result of value on a project.

One of the principal value-adds of using RUP is that RUP's guidance represents a factoring of activities into disciplines that has proven itself over time on a wide range of software projects. Having activities organized in this way provides a significant head start to projects that respect the disciplines.

Information on the standard RUP disciplines is available here.

The AOC SDP embellishes the core RUP guidance on disciplines in two important ways. These two concepts are best practices drawn from Extreme Programming: continuous integration, and relentless testing.

Continuous Integration is a simple concept that requires a lot of diligence and discipline to implement. Continuous integration means, in a nutshell, that all generated artifacts on a project are built at least once per day; and by "built" we mean that the artifacts are actually created from their source, and are fully tested by a robust suite of automated tests. Continuous integration also means that workers on a project size their tasks such that they can commit high-quality, well-tested source artifacts into the source control repository at least once per day. Continuous integration is a response to the traditional difficulty and risk associated with waiting until the end of a project or even the end of an iteration to acquire feedback on the suitability and quality of the system under construction. It establishes a daily rhythm whereby the project team gains concrete evidence of what has been accomplished, and also gains confidence that an acceptable level of quality is being maintained.

RFQQ-2004-01 Page 28 of 32

APPENDIX B

The idea of relentless testing represents a shift in emphasis from the "traditional" approach presented in the RUP guidance. The overall purpose of testing is still to verify and maintain an acceptable level of quality in the software. The twist is in how this is achieved. Traditionally, testing would proceed by exercising the user interface of the system, much as a user would, but in a controlled, planned way designed to reveal defects. To the extent possible, these tests were scripted and automated with a tool like Rational Robot, but the tests were still focused on exercising the GUI.

A layered, component-based, service-oriented architecture introduces new challenges and opportunities, which lead us in a new direction with respect to testing. The layers, components, and services in such an architecture are capable of being tested independently of the user interface(s) that sit on top of them. In fact, because the goal is to reuse services and components across UIs (or even in situations like batch jobs or web services that have no UI), it is crucial that they be tested independently of the UI.

Consequently, the Test discipline in the AOC SDP is heavily focused on programmatic, component-based testing. This is not to say that traditional GUI-oriented testing is not required or supported by the process. It's really an issue of emphasis.

For more information on Extreme Programming's relentless testing approach, see Testing Extreme Programming, by Lisa Crispin and Tip House, and Test-Driven Development by the founder of XP, Kent Beck. For a more in-depth coverage of patterns and models for testing object-oriented software, see Testing Object-Oriented Systems, by Robert Binder.

Roles in the AOC SDP

This section describes the roles played by people in the AOC SDP. For now, we just list the roles and map them to job descriptions; more detail will be added in the near future.

RFQQ-2004-01 Page 29 of 32

APPENDIX B

Table 1. Mapping of SDP Roles to Job Descriptions

Role Job DescriptionsConfiguration Manager Configuration Manager

Designer Senior Designer, Reuse Designer

Programmer Senior Java Programmer, Java Programmer, Apprentice Java Programmer

Project Manager Project ManagerTester TesterUI Designer UI Designer

RFQQ-2004-01 Page 30 of 32

APPENDIX C

STATE OF WASHINGTON




RFQQ-2004-01

APPENDIX C—DRAFT OF USER INTERFACE DESIGN PROCESS

Phases Tasks Products

Inception Step 1Complete Background Research

Review existing documentation. Review legislative mandates.

Step 2Participate In User Requirements Gathering

Conduct one-on-one interviews. Fulfill apprenticeship (observation period). Collect user artifacts. Identify user roles, contexts, characteristics, criteria, groups. Identify user tasks, work flows. Field interpretation of data.

User table by role and task. User scenarios.

Step 3Complete Data Interpretation And Modeling

Consult with Project Team on data. Contribute to Requirements Document.

User profiles. Use cases. Task flow model.

Step 4Participate With Project Team In Application/Module Design

Contribute to development of future task analysis per new app/module. Contribute to development of future task flow per new app/module.

Inception, continued

Elaboration Construction Step 5Identify Usability Objectives For Project

Review field notes, use cases, data models. Prioritize and allocate objectives to iteration cycles.

Step 6Produce Initial Interface Design Ideas

Sketch interface design ideas. Complete interface idea sketch reviews with Project Team, usability colleagues.

Designs.

Step 7Produce Initial Paper Prototype Designs

Mock up interface designs using paper. Complete interface design reviews with Project Team, usability colleagues.

Paper prototypes.

Step 8Conduct Heuristic Reviews Of Paper Prototypes

Mock up paper prototypes suitable for field review. Complete user reviews of designs in the field. Continue one-on-one interviews.

Paper prototypes.

RFQQ-2004-01 Page 31 of 32

APPENDIX C

Elaboration,continued

Construction, continued

Transition Step 9Construct Usability Testing Of Coded Screens, System

Create test scenarios. Recruit usability evaluators. Establish usability test schedule. Coordinate setup of coded screens/app/data/environment of testing. Conduct usability testing. Analyze usability test data. Draft preliminary findings memo.

Preliminary Findings memo.

Step 10Consult With Project Regarding Usability Findings

Meet with Project Team to review Preliminary Findings memo. Draft usability evaluation summary. Meet with Project Team to review Usability Evaluation Summary.

Step 11Produce Usability Reports And Recommendations

Review, edit, and revise Usability Evaluation Summary (at least two cycles).

RFQQ-2004-01 Page 32 of 32

Documents

STATE OF WASHINGTON 2004_01 - Consulting and... · Web viewEach page claimed to be exempt from disclosure must be clearly identified by the word “confidential ... on Extreme Programming's