|
|
 |
| |
| Software Engineering Process |
| |
|
Implementation
During the implementation discipline, most of the development-related activities take place. These activities include the actual
development, validation of the development products using a unit testing suite, creation of API documentation, and establishing a
deployment unit for migration to environments beyond development. In this respect, many of the artifacts produced as part of this
discipline are bi-products of development and may be produced in a continuous fashion using a variety of automation techniques.
Therefore, the artifacts included in the SEP may represent a higher degree of formality than is expected by many projects.
The SEP does not imply this level of formality; instead delegating this decision to the SEP customization process.
|
| |
|
Discipline Details
During the implementation discipline, the design artifacts are used by implementation and integration staff to create the implementation
artifacts that will form the basis of the running system. The primary artifact produced during the execution of this discipline is the
implementation element, which represents the collection of source code elements, third party libraries, configuration files, and other
similar elements needed to create the system. The other artifacts from the discipline are largely products of the assembly and integration
of the implementation elements into a working system: the log of unit test results, the report of software build operations, the deployable
software package, and the documentation for the APIs exposed by the application's domain objects.
|
| |
|
Activities
Implementation activities are completed by the software architect, system developers, and system integrators. Reviewers should also be used
to help ensure the quality of the software being produced is within acceptable tolerances. The primary activities completed during this
discipline are:
|
|
- Software implementation
- System integration
- Validation of implementation and integration activities
- Software build activities
|
|
Artifacts
Six artifacts are produced or refined as part of the implementation discipline. These artifacts are:
|
|
- Implementation Element - The implementation element artifact represents the collection of source code elements, third
party libraries, configuration files, and other similar elements needed to create the system. This artifact is the primary
output of the implementation discipline.
- Unit Test Log - The unit test log artifact reports the output of unit tests ran during execution of the implementation
discipline. The log may be the output of automated unit testing tools, if used. Otherwise, it is the collection of unit test
cases and test case results executed by the system developers.
- Build Manifest - The build manifest artifact is the output of the steps taken to, at a minimum, compile, test, and package
the application. The artifact is almost always the results of an automated build process, which at times may be verbose and
lengthy for a large application.
- Deployment Unit - The deployment unit artifact is the software application in a form that may be deployed to a staging or
production environment. Source implementation elements, that are not necessary to the functioning of the application, should
be omitted from the deployment unit.
- API Documentation - API documentation is just one type of documentation produced for an application; it is the most pertinent
to the ongoing maintenance of the application. API documentation should be produced using XML source code comments combined with
the JavaDoc or NDoc utilities.
- Deployment Document - The deployment document artifact contains, by reference, much of the information from other implementation
artifacts. In addition, it contains detailed deployment information, including the product installation instructions, release notes,
and a release manifest.
|
|
Tools
A variety of tools are used to support implementation activities and assist with the creation of artifacts for this discipline. These
tools are outlined below:
|
|
- Software Development Tools - The software development tools category is fairly broad, covering the Integrated Development Environments
used for development and compilation and integration tools that support the software development process. The SEP lists only the major tools
under this category and does not purport to being a comprehensive list of all tools used for development.
- Unit Testing Tools - Unit testing tools are used to perform method level tests of the application APIs. Unit tests are the earliest tests
of working application code and are consequently extremely important in mitigating more expensive bugs that are discovered later in the
development lifecycle. Automated unit testing tools exist for both Java and .NET. These tools can be used to build comprehensive test suites
that can be run either from GUI-based tools or as part of the application's build process.
- Build Tools - Build tools are a fairly broad classification for any number of structured scripting approaches to compiling, testing,
documenting, and deploying software applications. These tools derive a common lineage from older "Make" style files. Both Java and .NET have
a number of automated build tools available, most of which are now highly configurable and driven by XML-based configuration files.
- Deployment Packaging Tools - Deployment packaging tools enable software development teams to provide a clear packaging structure for the
application to be installed across multiple environments. These packaging tools range from simple Zip utilities to complex shrink wrapped
programs that not only create deployment packages but also run a number of ancillary activities, such as legacy component registration and
database setup activities.
- Source Code Documentation Tools - Source code documentation tools are used to extract structured comments from within source code, link
them to external resources, and create documentation in a number of formats (most commonly HTML). Both Java and .NET include such facilities,
by means of JavaDoc and NDoc for Java and .NET, respectively.
External Dependencies
There are no external dependencies associated with this discipline.
|
|
| Copyright© 2006-2009 Lorenzo Oldain Thompson, CPA, P.A. All Rights Reserved. |
|
|
|