Engineering Activities
Apply effective engineering methods to construct technology products ready for deployment.
|
|
||||||||||||||||
Introduction
These technical activities are performed in a development environment for one or more technology fabrication projects. These activities produce IT products and associated by-products that have the following characteristics:
- Are used by other projects as a part of their products (interproject dependencies are described in the IT Evolution Plan
- Are used by the acquisition activities as technical criteria to guide a commercial purchase or procurement contact. Fabrication projects also may adapt products purchased for HS Agency use.
- Are ready to integrate into the developmental configuration and directly deploy into the business, development, or technical operations environments.
IT products take many forms, from individual components, to complete integrated applications adapted from packaged solutions, commercial platforms, and information appliances, or systems transferred from another State - configured for use within the HS Agency environment. The background for the Technical Architecture Guide describes basic types of technology-related entities that may be produced. Documentation necessary to maintain and use these items is considered a product of the engineering activities. This documentation can include user, maintenance, installation, or operation manuals, as well as associated technical training materials.
IT by-products include engineering data and documentation that are generated and used to support the engineering process. These by-products may include process-related documentation, tools, scripts, and scaffolding, such as test generators, emulators, and databases.
The IT products may be unique to an HS program or can be shared across them, such as implementing a common application front end or portal. IT products are placed under formal change management by the support activities when delivered by the project.
Engineering practices, as well as overall adjunct technical requirements, are derived from the A-TARS. Unique product requirements are elicited from the HS program staff (e.g., TANF functional requirements). All product and process requirements are levied through each project's plans.
|
Activities
Key software-oriented activities performed on one or more fabrication projects are described below:
-
Custom-Built Application Life-Cycle Activities. A fabrication project may create or maintain unique applications that address specific HS program business needs. The size and complexity of an application product and uncertainty in a project's outcome (i.e., risks) influence how the engineering activities are partitioned across projects. For example, a conceptual prototype could be developed by one project to establish design goals and functional requirements for another project. The second project would implement those requirements and may reuse portions of the prototype's source code, delivering a robust application. Identifying the projects and their (input/output) dependencies is part of the Technical Evolution Planning and Management activities. The types of applications and their constituent parts are categorized in the TRM in the A-TARS (see the Technical Architecture Guide).
The following activities assume that the target application platform is defined and available to the development staff. Key activities are:
-
Problem analysis and application requirements specification. These activities establish the engineering design and implementation goals for an application. This involves eliciting needs, expectations, and constraints from the stakeholders and translating them into product design and implementation criteria. Applicable portions of the A-TARS set the overarching technical requirements. Any program or application-unique requirements must be consistent with the A-TARS, or waivers must be granted. Key portions of the A-TARS are the:
-
Boundary descriptions (identifying external entities, settings, and usage expectations)
-
Application or system architectures (application partitioning and allocation across processing nodes)
-
Service descriptions (identifying the appropriate software interface constraints)
-
Overarching principles (quality criteria and guidelines for target platform design)
-
Engineering methods to be employed include business process modeling, usage scenarios, prototypes, demonstrations, brainstorming, market surveys, QFD, and others. The result of these activities is agreement on a product specification and any supporting documentation, such as a concept of operations or use cases.
-
Application design and composition. The fabrication project activities assume a compositional approach based on component reuse, as noted in the overarching principles. A significant portion of an application's top-level design should have been addressed before a specific application product is built. An application's design is based on the application architecture(s) defined in the A-TARS, as implemented on the target application platforms. This includes the use of shared components, application templates, or use of an integrated development environment. You also could develop helper applications or data to aid testing or emulating the operational environment (e.g., cell phone presentation emulators and test databases). you should generate design notes or documentation to aid maintenance of the application (or part). Also you could produce technical user documentation or technical training materials, such as user or operator manuals.
-
Application verification. Examine individual parts of the application separately to establish that they meet technical requirements. For verification, you can use any method, including unit-level testing, peer reviews, or demonstration, as noted in the project's plan. The engineering practices and product characteristics must conform to the A-TARS. When the application is determined to meets its design goals, then place it and accompanying data under formal CM (see support activities).
-
Application maintenance. Maintenance is considered a special case of the application life-cycle activities, where the scope of change is usually small in reaction to a latent defect or usage/requirement change. Perform the appropriate analysis, design, composition, and verification activities. Perform regression testing to ensure that changes did not affect existing functionality or performance characteristics negatively (e.g., replacing a shared component with a newer version and maintaining backward-compatible interfaces or transaction performance). You may update and use helper applications or test data for application verification. The most recent version of the A-TARS may not be applicable because the technology in the maintained entity may no longer be part of the Technical Architecture (e.g., coding guidelines for a COBOL-based application where the A-TARS recommends Java). In this case, reference and use the previous version of the A-TARS unless the application is intended to migrate to the current A-TARS.
-
Migration-oriented activities. Migration of an application or part of an application is achieved through the actions of the other application engineering activities. Automated tools and procedures may be used heavily, scaffolding (e.g., adaptors) to bridge heterogeneous environments may be needed. This could include scripts or procedures to migrate data from one storage system to another. You should test these scripts and procedures within the development environment and execute them during deployment to migrate operational data in concert with the newly deployed applications.
-
Application retirement. Projects make the end-of-life decision for a technology during the strategic IT planning process. The relevant applications and all dependent items are removed from the IT inventory. This process may include uninstalling and removing of any application and its associated pieces (directories, registry settings, data files, or user documentation). You may want to archive application data. It may be necessary to retire equipment (removal of legacy devices or platforms). Retirement may have security/privacy considerations, especially if the items will be resold or transferred to another usage environment. This may require actions to purge data from magnetic media or other destruction procedures. Software subscriptions and licensing also may need to be cancelled, as coordinated with the acquisition activities.
-
-
Target Platform Life-Cycle Activities. A Target Architecture is developed in accordance with the system and application architectures defined in the A-TARS. It is designed to satisfy the unique needs of the hosted applications and to meet specific product requirements (e.g., processing performance, disk size, and memory size requirements). Generally, the Target Architecture is based on commercial products. These products are acquired, adapted, and configured to form the Target Application Platform. That physical platform is the basis upon which the applications are designed, built, acquired, and executed.
The design of the Target Architecture's technology-related entities must conform to the A-TARS to minimize the risk of becoming overly dependent on a vendor's unique capabilities. Members of the Technical Architecture Team will advise, review, and approve the Target Architecture before products are purchased. When a vendor-provided product conforms to the Technical Architecture descriptions, it can be used directly to build applications (e.g., a conforming implementation of a service API. Otherwise, programming guidelines, wrappers, or other adapters may be needed to maintain a degree of application-vendor independence, as required by the A-TARS. For example, the target platform design may wrap a vendor component within another, exposing an A-TARS, compliant service interface to the applications while hiding the vendor's version. This limits application programmer access to vendor extensions, which can be verified during code peer reviews. The vendor component can be replaced later with another vendor's product with little or no direct application changes; only the wrapper implementation would change. When cost, performance, or other design considerations are justified, exceptions to parts of the A-TARS can be negotiated with the architects and waivers granted on a case-by-case basis.
Not only is the target for the operational environment defined and assembled, the development environment also could be impacted. This may occur when a new type of computer platform is introduced into the HS Agency (e.g., moving from mainframe-based to distributed application server-based solutions). You may create guidelines on application development and use of tools and integrate them into the development environment, in accordance with A-TARS process-oriented guidelines. In some cases, you may want to feed the lessons learned from pioneering projects back into the A-TARS.
These activities coordinate with the acquisition activities to acquire products meeting Target Architecture criteria. The support activities will maintain the configurations. All products are tested and verified against the Target Architecture before hosting applications (e.g., performance, security, or other essential properties).
-
Application-Adaptation Activities. Applications may be constructed using commercially available components, such as custom controls or business objects; prepackaged solutions; other applications (e.g., office suite automation objects); or complete integrated systems (e.g., specialized servers, such as data store or business gateways). These items are subject to the same disciplines as those for defining and building the target application platform. The goal is to establish and control how applications will be built on top of these products to limit the impact of vendor lock-in, while taking advantage of the product's unique features (most likely the reason it was selected in the first place). Products will be tested before building applications on them (e.g., maximum transaction rates, security, availability) and guidelines provided to the application builders.
-
Solution Integration and Test Activities. Each fabrication project may build a portion of the overall AIS. Even though each project verifies that its part is complete and meets allocated requirements, you must integrate the set of parts and test them as a whole. A fabrication project is created to receive each part and construct the developmental configuration, preparing it for deployment. Each release undergoes development testing and evaluation to ensure that it meets the technical goals for the plateau. This testing is highly repeatable and may rely on simulated workloads, data, or emulation of devices or platforms.
Focus a significant portion of integration and testing on external system interfaces (e.g., Medicaid, SACWIS, Child Support Enforcement, Courts, Social Security Administration). Confidence should be high in the application's ability to maintain the accuracy and integrity of any exchanged data. You need to use test data, test cases, and detailed manual or automated test procedures to monitor and verify external system interfaces. You may need to use emulators and test scripts to exercise interfaces for nominal and exception conditions, and to allow for cost-effective regression testing.
The result of this testing is a major factor in the decision to release for deployment. In essence, the engineering requirements that were allocated to the products that project's produced have been satisfied adequately. The IT decision makers for the plateau make this determination.
Roles and Responsibilities
The key roles and their responsibilities are as follows:
- IT Staff. These individuals perform the technical activities. They may perform analysis, programming, network design and implementation, database design and implementation, testing, user interface development, Web content development, technical documentation, and many more types of activities. They may be organized on interdisciplinary or specialty teams, sharing expertise across projects in accordance with the project's staffing profiles.
- Technical Architecture Team. These individuals provide assistance and review of the technical practices and products to ensure consistency with the appropriate part of the A-TARS. They may participate in peer reviews or other formal design reviews.
- Support Organization. Individuals with expertise in the QA or CM disciplines provide assistance to the IT staff. These individuals may help establish and review practices to ensure proper accounting of all product elements and quality oversight of technical processes and products.
- Other Key Stakeholders. This includes any group or individual with a vested interest in the project's products (e.g., the customer). This may include staff from other projects that will build on the project's products or business user representatives (e.g., participating in sessions to establish technical requirements and review designs). The IT Project Manager and other management groups may review technical progress. State procurement personnel also may participate (e.g., when the project defines specifications that will be used to acquire conforming products).
Artifacts
The following information is used or produced by these activities. Templates, examples, and checklists for identifying and documenting items are available through the Additional Resources section at the end of this page.
- IT Products and Data. This is the main result of these activities. The output products and data may be new or may build upon other products and data. When maintenance activities are performed, the previous version of the product and data will be updated.
- IT Project Plans. Each engineering task is formally managed in accordance with the project's plan.
- Project or Product Requirements. These are allocated to the engineering tasks to ensure that both the engineering practices employed and the resultant IT products and data conform to the HS Agency and HS programs' needs.
- A-TARS. The appropriate part of the A-TARS is used to guide technical decisions for the project. Any IT products and data produced by the project must be verified against the A-TARS.
- Status. Technical progress and issues are forwarded to the project management activities. Status is against the tasks in the Project Plan.
Additional Resources
Resources applicable to this activity are cataloged below. Lists of all available resources may be found in the Resources portion of the IT Planning and Management Guides.
| Consolidated List - Software Engineering Resources Contains links to sites that further list software engineering practices and related topics. 03-3-02 |