Embed Size (px)
Citation preview
Announcing Principles of Biology, an Interactive Textbook by Nature EducationNature Education Platform allows creation of highly interactive textbooks intended for college-level science books. The first textbook in the series, Principles of Biology, is intended for university-level biology courses. The first title in the series is Principles of Biology, intended for introductory biology classes. Principles of Biology consists of 200 customizable modules collectively covering chemistry, genetics, cell biology, animal physiology, plant physiology, and ecology. Each module is a self-contained learning experience, combining textual instruction, high quality figures, simulations, interactive exercises, self-tests, and formal tests. Each module also draws on the Nature journals' extensive archive of research papers to help students develop mature scientific skills, including data analysis and critical thinking. Created by a group of more than 100 scientists, instructors, scientific illustrators, interaction designers, and faculty reviewers working together under the guidance of Nature Education's editorial team, Principles of Biology is accessible to students and instructors on desktops, laptops, tablet computers and smartphones.
The Principles of Biology PhilosophyWhile Principles of Biology has been carefully authored to reflect the highest, timeless values of educational publishing, including high quality explanations, clear artwork, and thoughtful pedagogy, it also reflects a number of special characteristics emblematic of Nature Education's philosophy.Focused on Real ScienceBecause it's created by the publishers of Nature and Scientific American, Principles of Biology is filled with discussion of the real world of scientific research.
Primary Literature Summaries Principles of Biology contains more than 100 classic papers from Nature and other NPG journals along with synopses specially written to help undergraduates begin to develop an understanding of how scientific research is communicated and analyzed.
Lenses on Biology An ongoing series of investigations into how biological research impacts the quality of life on Earth. Written by a leading scientist each piece explores a key area of scientific focus from a range of perspectives, including historical development, current research, and future potential. Lenses on Biology is intended to help students understand why the science they are learning is critical, and to encourage them to seriously consider a research career.
Bioskills Principles of Biology contains more than 40 special sections designed to help students begin to develop real-world scientific skills, include data analysis and interpretation and experimental design.
Careers More than 30 special sections help the student explore the range of scientific careers that are related to the material they are studying, including research, teaching, journalism, law, and more.
1
Born DigitalAs the first major textbook designed specifically for the digital world, Principles of Biology takes full advantage of the many benefits of the digital medium.
Integrated Learning Each module integrates text, high quality figures, interactive exercises, simulations, video, and assessments into a single, rich flow of learning for the student.
Customization Instructors can easily customize Principles of Biology by rearranging or deleting any of the 200 modules, adding their own material, and turning on and off particular sections within the modules.
Anytime, Everywhere Access All content in Principles of Biology is fully accessible on desktop and laptop computers, mobile phones, and tablet computers, ensuring that you and your students can take advantage of the material wherever you are.
Real-time Gradebook Each of the 200 modules in Principles of Biology concludes with a multiple-choice online test of key concepts covered. The results from this test feed automatically into a gradebook, allowing instructors to track how their class as a whole is grasping the material down the level of individual questions and learning objectives.
Simple to UsePrinciples of Biology is designed to meet the needs of today's classrooms.
2
Instructor Supplements Principles of Biology comes with a rich set of instructor supplements, including an Instructors Guide, downloadable versions of all art, a library of classic research papers from NPG journals, and a test bank containing 1000+ downloadable questions.
Student Supplements Students have access to automatically created Study Cards that summarize the key concepts in each chapter, a rich Study Guide, and two special ebooks just for science students: English Communication for Science Undergraduates, and Nature's Guide to Life Science Careers
Accessibility Principles of Biology fully supports the needs of students with disabilities, including non-sighted, vision impaired, color vision impaired, and mobility impaired students.
Research-oriented and born digital Principles of Biology is an ideal tool to help today's scientists teach the next generation of students to have a lifelong relationship with biology.
Nated Application Architectural Overview and
Best Practices
3
In the above diagram, the basic layout of the nated application architecture has been depicted. Apache HTTPD Server 2.2 has been used as web server and Apache Tomcat 6 has been used as application server for this application. Below you can find the basic flow of a request and the involvement of the various components in a typical request cycle. HTTP Request from client to Apache Web Server:
Whenever a request is fired from any web client, at the very beginning the request reaches to the Varnish webcache and then to Apache Web Server, from where an AJP request is fired to the Tomcat Server.
Processing Request inside web filter:
Inside Tomcat the nated application handles the request. A web filter URLRewriteFilter has been configure for all kind of requests which is the first stop for all the requests. Below are the jobs that is performed for each of the requests:
a. The device (desktop / mobile / iPad) is detected from where the request is coming. If this is a request is coming from a non-desktop device, the requested URL is changed (the requested URL http://www.nature.com/principles/nated/student-catalog is converted to http://www.nature.com/principles/nated/m.student-catalog)
4
b. The clean URL is converted to dirty URL (http://www.nature.com/principles/nated/student-catalog to http://www.nature.com/principles/nated/group?action=getGradeClassGroupsForStudentsCatalog) with the help of the XML file urlrewrite.xml and the request is dispatched to the changed URL pattern to point the specific servlet and action class.
Controller (Servlet, Action):
Servlet and Action together acts as the controllers for the application. There are serveral servlets present in this application that acts as the front layer of the controller layer for different modules of the application (resources, group, assessment etc.) and redirects the requests to different Actions.
Service classes:
Various baceknd functionalities are exposed to the action classes through the service APIs. Each service method typically do the following operations:
i. Connection (wrapped in NatedDBConnection) is retrieved from pool. If the service is for data fetching purpose autocommit (for Connection object) is kept as true (by setting isTransaction flag as false and passing the flag to the API BaseService.getConnection(isTransactio)) else this is kept as true.
ii. APIs from different BO (business object) or different util classes (e.g. CourseUtil) are called.
iii. After the method is completed, commit (BaseService) is called and the connection is closed in the finnaly block.
iv. The data are typically wrappped in various TransferObjects (these are serializable objects that contains different parameters and corresponding getter and setter methods) and sent to the action classes.
v. In the catch block, rollBack (BaseService) is called for the data manipulation based services.
Model (Business Objects):
Business Objects are used as model in this application. Each class contains the properties of the entity this is representing (e.g. User, Course etc.) and the getter-setter methods. Below are the other important parts of the classes:
Pk Constructor – This type of constructor takes the primary key of the entity and the connection (NatEdDBConnection) as arguments. This is used to construct the BO object corresponding to the PK of the entity with the data as stored in DB. This calls the DAO method to get the details from DB.
5
TO Constructor – This constructor takes the transfer object corresponding to the entity as the arguments and used for constructing the BO object with the data (except the PK) comes with the transfer object from the front layer. This constructor is typically used when this is required to insert the data for an entity in DB and the PK is not avaiable while the object is constructed.
save (NatEdDBConnection natEdDBConnection) – This is a private method which is called by two public methods insert and update to save the data in DB.
Other static and non-static methods for manipulating or retrieving informations of the corresponding entities of the business objects.
Populate TO – which is used to populate the corresponding TO from the BO. This method is getting called form service after the PK constructor is called of the BO and need to transfer the data back to Action Layer from service.
Business objects in turn access the DAO (Data Access Objects) classess, Marklogic access Class (MarkLogicAccessObject) or the other util classes (e.g. FileUtils) for accessing the persistent storages like databases, marklogic or file system.
6
Device DetectorDevice Atlas
Flex in Adobe Air
XSL FO
JQuery
JAXB
XSLT
CSS
JSP
Servlet
Java 6Utility ToolsServer Components
Video Converter
FFMpeg
Image ProcessorImage Magick
PDF Generator
RenderX
Client Side CachingAkamai, Netstorage
WebServerApache HTTP 2.2
Chat ServerEjabbered
Application ServerTomcat 6
Server Side Caching
Memcached
Search EngineLucene
XML ServerMarklogic
DataBase Server
MySQL 5.5
7
Hardware infrastructure of Nature Educaiton Platform
9
87
6
5
4
3
2
1
Package Downloaded from Akamai
Student Package Creation Request Delegated
Student Package Uploaded
Student Package Stored
Master Package Stored
Akamai Net Storage
File System
Master Package Creation Request Delegated
Master Package Creation Request
while Book is Published
Student Package
Download Request
URL
Request For Student Package
Download
Ebook Packager Server
(Tomcat 6.0) – Instance 2
Nated Education Server
(Tomcat 6.0) – Instance 1
AIR Desktop eReader
8
An introduction to the Science Curriculum Platform The Science Curriculum Platform (or SCP) is primarily designed to allow
Macmillan Education publishing staff to create, edit and deploy online and offline digital products with as little reference to programmers or designers as possible.
In some cases it is possible to create a digital product without any technical input at all using an online tool.
Content in the platform can be linked to one or more curricula and with any number of tags to facilitate re-use across products and Macmillan divisions.
It’s known as the Science Curriculum Platform for historical reasons, but it works in any subject explicitly including ELT.
The following vocabulary is used in the description of the components below:
A portal is a set of web pages which allow login to Macmillan products (e.g. http://www.onestopdigital.com.au/ )
The registration application is used by a user when they are entering a product access code or paying by credit card.
Multiple products (e.g. Get Real Foundation Level Digibook) are accessed through the portal.
Products are created and published using the online publishing tool. Each product is composed of interactions (e.g. Main menu; a test on the
eye). Every interaction is of an interaction type (e.g. Menu screen, Page-
faithful ebook, test, table of contents). A widget is a special interaction type which can be launched modally on
top of others - for example, a box displaying teachers' notes (as in CultureWorld).
A price pack is the combination of a product, a business model, a price, and a duration. A site licence to VCE Psychology for 12 months at AUD140.00 would be an example. For the technical, price packs correspond to SAMS products.
CultureWorld is a highly bespoke product created for Cultura Inglesa Sao Paolo using the SCP, which interfaces with Macmillan English Campus via an API.
Getting technicalThe SCP is also a modular, scalable, interoperable, extensible, re-skinnable set of technologies entirely owned by Macmillan which provide a base set of functionalities and APIs on which bespoke, highly customised digital publishing can be built. This is built on HTML/Javascript and Flash client-side components calling SOAP web services and JSON REST server-side. The platform is hosted on the Microsoft Azure Cloud and Amazon S3, and includes the deployment of a Content Delivery Network to maximize download speeds. The available technologies include a common content data model, single sign on, and a
9
common user data store including a markbook. These ensure that Macmillan can retain control over its data model and user data.
Architecture Summary
The above diagram summarises the components of the platform and their communication. Each component and its interconnections are described in detail below. Components visible to end users are in black with white text.
The fundamental components: the three core stacksThe fundamental components of the system are the three stacks in grey, red and green. Each stack consists of a SQL Server 2008 R2 database and an associated set of SOAP web service methods and REST calls allowing information to be inserted, updated and deleted in these databases. All web services output XML; all rest calls output JSON. The web services are written in C#/ .NET 3.5 and 4.0.
The publishing stack (in grey) allows for the creation, assembly, editing and publication of SCP products by Macmillan and third party developers.
o Macmillan has developed the Publishing Tool as an interface onto the publishing stack to allow the creation of simple products.
o Third party developers have developed helper applications to read and write more complex interaction configuration information.
10
The production stack (in red) stores and delivers snapshots of products and their associated interactions derived from the publishing database, plus information about portals.
o In the publishing database, products, interactions and their associated media items are stored in separate tables; in the production database, an XML snapshot of an entire product configuration file is stored as one flattened blob. The transfer and flattening of this information is accomplished by the set live process. Customer-facing portals and product HTML pages only ever request portal and product configuration information from the production database, ensuring efficiency and scalability.
The users stack (in green) stores, delivers and updates information about users: their marks, their classes, their user-generated content.
o .
Other components SAMS (in orange) is a third party, off-the-shelf application for managing
single sign-on (SSO). It manages users' authentication and authorisation for online content and their associated credentials.
All components of the SCP access SAMS via its REST API, for which documentation is available directly from SAMS.
A Portal (black and white) is one or more HTML pages which allow an SCP customer access to one or more products. A single product may be accessible from more than one portal. Thus far portals have been developed as static HTML pages which use Javascript to access the production and user REST APIs to deliver login and product access pages to the user.
The Product launched by portal is the HTML which starts the product rendering process for a user. This consists of configuration information, passed into the page via the GET query string, and the Wrapper which hosts all the code which renders a product. Currently the Wrapper is written in Flash 10, and the configuration information, including the user authentication hash (see securing communication, below) is passed into Flash as Flashvars. The Wrapper then requests the full product configuration XML from the production web services and configures itself from there, pulling in functional components and skins as necessary. An HTML5 wrapper is currently in the development roadmap
The Registration application provides an online interface for customers to redeem access codes, register for products, pay by credit card, and manage their profile information (including changing their passwords). It is re-skinnable and interfaces extensively with SAMS and the user stack.
11
Securing communicationCommunication between the various components is secured in four ways. In many cases more than one method is used.
1. Username and password2. 24-hour authentication hash: a hash of the username, plus the date, is
combined with a secret "salt" code to create a hexadecimal string of letters and numbers. The username and a hash are provided in every request to a web service. The web service re-hashes the username using the date and code and compares it to the hash which is in the request - if they do not match, the request is rejected. The hash is therefore valid for 24 hours. (Note: in fact the hash is compared to the hash for the previous day and the next day as well as the current day, to avoid time zone problems between servers; this means that in some cases a hash may last 48 hours).
3. Account hash: a hash of the account id, plus another secret salt. This is stored in a cookie and removes the need for users to login continually, but is inherently relatively insecure.
4. SSL - this protects the information between the user's browser and the server, but clearly does not authenticate or authorise the user.
5. Digital certificate.
Communication between the Wrapper and the production or user web services is secured by the use of a 24-hour authentication hash and, for particular write methods requiring additional security, username and password plus 24-hour authentication hash.
Most REST calls are publicly accessible with no authentication as they are read-only and contain publicly available information. Others rely on the account hash, but these are accessing relatively unimportant information.
Communication between the Publishing Tool and third party web applications is ensured by the use of a separate publisher authentication hash which uses a different salt to that used by customers.
Communication between any application and SAMS is enforced by the use of a digital certificate in the REST request, which is conducted over SSL. This is invisible to users as the request comes from the stack web server rather than the user client.
All pages in the Registration Application are SSL transmitted in the live environment. Login from any portal is "bounced" via SSL to the registration tool so that usernames and passwords remain secure - an account hash is then passed back to the HTML page in the GET.
Design rationaleThis design ensures that the SCP is highly flexible and can be used for a very wide range of applications, with a very rigorous separation of the different application layers. It is:
Modular - one or more pieces can be used independently of each other.
12
Scaleable - the architecture is stateless and the three core stacks can be scaled horizontally and vertically.
For advanced developers, it places few constraints on the user experience.
HostingThree separate instances of the platform are hosted: development, training and production. The first and last are self-explanatory: the second is for staging, deployment and previewing of functionality which needs to be reviewed by non-technical staff.
The platform is hosted primarily on Microsoft Azure,using both SQL Azure and the AppFabric. Our servers are in the Northern European datacentre in Ireland.
Using Azure means that Macmillan is only responsible for hosting at the application level: Microsoft are concerned with operating system, hardware and software patching. Azure provides an SLA of 99.95% availability for web servers and 99.9% for databases.
There is also reliance on a Flash Media Server for voice record and playback functionality, and the server hosting this wiki and source code repository, which are also hosted on EC2.
Binary files for the platform are held on Amazon S3. The Flash engine and shared Javascript files for the platform are held in three subdirectories corresponding to platform instances: prod, training and dev.
SAMS is hosted separately by Semantico. There are testing/development and live servers.
The Platform co-ordinator holds the details of all relevant authentication and authorization credentials.
Backup: The main production databases for the three production stacks (production, users and publishing) are synchronised every 15 minutes to a server held in the USA on Amazon EC2 and further backed up to Amazon EBS instances every day. This server doubles as the reporting server, which provides a web app for internal users to view reports on the platform, powered by an associated program which runs as a scheduled task.
13
1. The Scope of Life CyclesMacmillan uses Enterprise Unified process which combines best of traditional software development process with Agile Scrum development.
This SDLC is comprised of six phases: Iteration -1, Iteration 0/Warm Up , Construction, Release/End Game, Production, and Retirement.
Figure 2. A detailed agile SDLC.
Figure 3. The Enterprise Unified Process (EUP) life cycle.
14
Figure 4. The Agile SDLC (high-level).
On the surface, the agile SDLC of Figure 4 looks very much like a traditional SDLC, but when you dive deeper you quickly discover that this isn't the case. This is particularly true when you consider the detailed view of Figure 2. Because the agile SDLC is highly collaborative, iterative, and incremental the roles which people take are much more robust than on traditional projects. In the traditional world a business analyst created a requirements model that is handed off to an architect who creates design models that are handed off to a coder who writes programs which are handed off to a tester and so on. On an agile project, developers work closely with their stakeholders to understand their needs, they pair together to implement and test their solution, and the solution is shown to the stakeholder for quick feedback. Instead of specialists handing artifacts to one another, and thereby injecting defects at every step along the way, agile developers are generalizing specialists with full life cycle skills.
2. Iteration -1: Pre-Project PlanningIteration -1, the “pre-Inception phase” in the Enterprise Unified Process (EUP), is the pre-project aspects of portfolio management. During this phase you will:
1. Define the business opportunity. You must consider the bigger business picture and focus on market concerns. This includes exploring how the new functionality will improve your organization’s presence in the market, how it will impact profitability, and how it will impact the people within your organization. This exploration effort should be brief, not all projects will make the initial cut so you only want to invest enough effort at this point to get a good “gut feel” for the business potential. A good strategy is to follow Outside-In Development’s focus on identifying the potential stakeholders and their goals, key information to help identify the scope of the effort.
2. Identify a viable for the project. There are several issues to consider when identifying a potential strategy for the project. For example, do you build a new system or buy an existing package and modify it? If you decide to build, do you do so onshore or offshore? Will the work be solely done by your own development team, by a team from a system integrator (SI), or in partnership with the SI? What development paradigm – traditional/waterfall, iterative, or agile – will you follow? Will the team be co-located, near-located within the same geographic region, or far-located around the world? As you can see there are many combinations of strategy available to you, and at this point in time you may only be
15
able to narrow the range of the possibilities but be forced to leave the final decision to the project team in future iterations.
3. Assess the feasibility. During Iteration -1 you will want to do just enough feasibility analysis to determine if it makes sense to invest in the potential project. Depending on the situation you may choose to invest very little effort in considering feasibility, for many systems just considering these issues for a few minutes is sufficient for now, and for some systems you may choose to invest days if not weeks exploring feasibility. Many organizations choose to do just a little bit of feasibility analysis during Iteration -1, and then if they decide to fund the project they will invest more effort during Iteration 0. In my experience you need to consider four issues when exploring feasibility: economic feasibility, technical feasibility, operational feasibility, and political feasibility. Your feasibility analysis efforts should also produce a list of potential risks and criteria against which to make go/no-go decisions at key milestone points during your project. Remember that agile teams only have a success rate of 72%, compared to 63% for traditional projects, implying that almost 30% of agile projects are considered failures. Therefore you should question the feasibility of the project throughout the life cycle to reduce overall project risk.
Iteration -1 activities can and should be as agile as you can possibly make it – you should collaborate with stakeholders who are knowledgeable enough and motivated enough to consider this potential project and invest in just enough effort to decide whether to consider funding the effort further.
3. Iteration 0/Warm Up: Project InitiationThe first week or so of an agile project is often referred to as “Iteration 0” (or "Cycle 0") or in The Eclipse Way the "Warm Up" iteration. Your goal during this period is to initiate the project by:
1. Garnering initial support and funding for the project. This may have been already achieved via your portfolio management efforts, but realistically at some point somebody is going to ask what are we going to get, how much is it going to cost, and how long is it going to take. You need to be able to provide reasonable, although potentially evolving, answers to these questions if you're going to get permission to work on the project. You may need to justify your project via a feasibility study.
2. Actively working with stakeholders to initially model the scope of the system. As you see in Figure 5, during Iteration 0 agilists will do some initial requirements modeling with their stakeholders to identify the initial, albeit high-level, requirements for the system. To promote active stakeholder participation you should use inclusive tools, such as index cards and white boards to do this modeling – our goal is to understand the problem and solution domain, not to create mounds of documentation. The details of these requirements are modeled on a just in time (JIT) basis in model storming sessions during the development cycles.
3. Starting to build the team. Although your team will evolve over time, at the beginning of a development project you will need to start identifying key team members and start bringing them onto the team. At this point you will want to have at least one or two senior developers, the project coach/manager, and one or more stakeholder representatives.
4. Modeling an initial architecture for the system. Early in the project you need to have at least a general idea of how you're going to build the system. Is it a mainframe COBOL application? A .Net application? J2EE? Something else? As you see in Figure 5,
16
the developers on the project will get together in a room, often around a whiteboard, discuss and then sketch out a potential architecture for the system. This architecture will likely evolve over time, it will not be very detailed yet (it just needs to be good enough for now), and very little documentation (if any) needs to be written. The goal is to identify an architectural strategy, not write mounds of documentation. You will work through the design details later during development cycles in model storming sessions and via TDD.
5. Setting up the environment. You need workstations, development tools, a work area, ... for the team. You don't need access to all of these resources right away, although at the start of the project you will need most of them.
6. Estimating the project. You'll need to put together an initial e stimate for your agile project based on the initial requirements, the initial architecture, and the skills of your team. This estimate will evolve throughout the project.
Figure 5: The Agile Model Driven Development (AMDD) life cycle.
The 2009 Agile Project Initiation Survey found that the average time to initiate an agile project took 3.9 weeks. Figure 6 depicts the range of initiation periods. Differences are the results of the complexity of the domain/problem space, technical complexity of what you're trying to accomplish, availability of stakeholders, ability of stakeholders to come to agreement as to the scope. and ability of the team to form itself and to obtain necessary resources.
Figure 6. How long did it take to initiate an agile project?
17
4. Construction Iterations
During construction iterations agilists incrementally deliver high-quality working software which meets the changing needs of our stakeholders, as overviewed in Figure 7. Figure 7. Agile software development process during a construction iteration.
18
We achieve this by:
1. Collaborating closely with both our stakeholders and with other developers. We do this to reduce risk through tightening the feedback cycle and by improving communication via closer collaboration.
2. Implementing functionality in priority order. We allow our stakeholders to change the requirements to meet their exact needs as they see fit. The stakeholders are given complete control over the scope, budget, and schedule – they get what they want and spend as much as they want for as long as they’re willing to do so.
3. Analyzing and designing. We analyze individual requirements by model storming on a just-in-time (JIT) basis for a few minutes before spending several hours or days implementing the requirement. Guided by our architecture models, often hand-sketched diagrams, we take a highly-collaborative, test-driven design (TDD) approach to development (see Figure 8) where we iteratively write a test and then write just enough production code to fulfill that test. Sometimes, particularly for complex requirements or for design issues requiring significant forethought, we will model just a bit ahead to ensure that the developers don't need to wait for information.
4. Ensuring quality. Agilists are firm believers in following guidance such as coding conventions and modeling style guidelines. Furthermore, we refactor our application code and/or our database schema as required to ensure that we have the best design possible.
19
5. Regularly delivering working software. At the end of each development cycle/iteration you should have a partial, working system to show people. Better yet, you should be able to deploy this software into a pre-production testing/QA sandbox for system integration testing. The sooner, and more often, you can do such testing the better. See Agile Testing and Quality Strategies: Discipline Over Rhetoric for more thoughts.
6. Testing, testing, and yes, testing. As you can see in Figure 9 agilists do a significant amount of t esting throughout construction. As part of construction we do confirmatory testing, a combination of developer testing at the design level and agile acceptance testing at the requirements level. In many ways confirmatory testing is the agile equivalent of "testing against the specification" because it confirms that the software which we've built to date works according to the intent of our stakeholders as we understand it today. This isn't the complete testing picture: Because we are producing working software on a regular basis, at least at the end of each iteration although ideally more often, we're in a position to deliver that working software to an independent test team for investigative testing. Investigative testing is done by test professionals who are good at finding defects which the developers have missed. These defects might pertain to usability or integration problems, sometimes they pertain to requirements which we missed or simply haven't implemented yet, and sometimes they pertain to things we simply didn't think to test for.
Figure 8. Taking a "test first" approach to construction.
20
I would rather fail three months into a two-year project
than three years into a two-year project.
5. Release Iterations(s): The "End Game"
During the release iteration(s), also known as the "end game", we transition the system into production. Not that for complex systems the end game may prove to be several iterations, although if you've done system and user testing during construction iterations (as indicated by Figure 6) this likely won't be the case. As you can see in Figure 10, there are several important aspects to this effort:
1. Final testing of the system. Final system and acceptance testing should be performed at this point, although as I pointed out earlier the majority of testing should be done during construction iterations. You may choose to pilot/beta test your system with a subset of the eventual end users. See the Full Life Cycle Object-Oriented Testing (FLOOT) method for more thoughts on testing.
2. Rework. There is no value testing the system if you don't plan to act on the defects that you find. You may not address all defects, but you should expect to fix some of them.
3. Finalization of any system and user documentation. Some documentation may have been written during construction iterations, but it typically isn't finalized until the system release itself has been finalized to avoid unnecessary rework Note that documentation is treated like any other requirement: it should be costed, prioritized, and created only if stakeholders are willing to invest in it. Agilists believe that if stakeholders
22
are smart enough to earn the money then they must also be smart enough to spend it appropriately.
4. Training. We train end users, operations staff, and support staff to work effectively with our system.
5. Deploy the system. See my article entitled System Deployment Tips and Techniques.
Figure 10. The AUP Deployment discipline workflow.
As you can see in Figure 11, on average agile teams take 4.6 weeks to transition their system into production according to the November 2010 Agile State of the Art Survey. As you can see in the figure there is a wide range of time taken. I believe this variance ranges based on the complexity of the solution, the amount of deployment automation (teams that have adopted a continuous deployment strategy automate many of the technical aspects of transition), the comprehensiveness of the agile testing effort during construction, the need for manual efforts
23
such as training and educating end users (or support or operations staff), and the organizational complexity of your environment.
Figure 11. Amount of time experienced agile teams invested in releasing/transitioning their solution into production.
6. ProductionThe goal of the Production Phase is to keep systems useful and productive after they have been deployed to the user community. This process will differ from organization to organization and perhaps even from system to system, but the fundamental goal remains the same: keep the system running and help users to use it. Shrink-wrapped software, for example, will not require operational support but will typically require a help desk to assist users. Organizations that implement systems for internal use will usually require an operational staff to run and monitor systems.
24
This phase ends when the release of a system has been slated for retirement or when support for that release has ended. The latter may occur immediately upon the release of a newer version, some time after the release of a newer version, or simply on a date that the business has decided to end support. This phase typically has one iteration because it applies to the operational lifetime of a single release of your software. There may be multiple iterations, however, if you defined multiple levels of support that your software will have over time.
7. RetirementThe goal of the Retirement Phase is the removal of a system release from production, and occasionally even the complete system itself, an activity also known as system decommissioning or system sunsetting. Retirement of systems is a serious issue faced by many organizations today as legacy systems are removed and replaced by new systems. You must strive to complete this effort with minimal impact to business operations. If you have tried this in the past, you know how complex it can be to execute successfully. System releases are removed from production for several reasons, including:
1. The system is being complete replaced. It is not uncommon to see homegrown systems for human resource functions being replaced by COTS systems such as SAP or Oracle Financials.
2. The release is no longer to be supported. Sometimes organizations will have several releases in production at the same time, and over time older releases are dropped.
3. The system no longer needed to support the current business model. A organization may explore a new business area by developing new systems only to discover that it is not cost effective.
4. The system is redundant. Organizations that grow by mergers and/or acquisitions often end up with redundant systems as they consolidate their operations.
5. The system has become obsolete.
In most cases, the retirement of older releases is a handled during the deployment of a newer version of the system and is a relatively simple exercise. Typically, the deployment of the new release includes steps to remove the previous release. There are times, however, when you do not retire a release simply because you deploy a newer version. This may happen if you can not require users to migrate to the new release or if you must maintain an older system for backward compatibility.
25
