This chapter is from the book
This chapter is from the book
This chapter is from the book
3.4 The Software Process
In this area we discuss the process-components that are responsible for software development. The other area containing three process-components is the quality process. (Please refer to the accompanying CD for a tabular list of the following process-components and a starting project plan based on them.)
3.4.1 Business Evaluation Process-Component
Figure 3.4 describes the process-component of business evaluation that describes the part of the process that deals with the prime reason why the project exists. This process-component also presents the very early approach to organizing the project. This is undertaken by the project sponsor, who starts with the activity of a business opportunity analysis. This is followed by a business proposal formulation. The steering committee performs the activity of project approval in an iterative fashion; the project manager handles the responsibilities of the project once the project is formed.
)
Figure 3.4 Process-component for business evaluation
This process-component is important when undertaking a formal evaluation of the business reasons why a software project should proceed. Not only does this argument help those who are going to manage the project, but it also helps to confirm, in the minds of the project sponsor and the eventual end users, the goals and objectives of the project. Because this process-component deals with the initial understanding of the business problem, the deliverables produced here form part of the Model Of the Problem Space (MOPS). They are the business case and the project brief.
3.4.2 Roles in Business Evaluation
The roles in business evaluation are as follows:
The steering committee deals with the highest-level management of the project. It brings together expertise from various domains including technology, business, human resources, accounting, finance, and legal, to name a few.
The project sponsor initiates the project, benefits from it, and pays for it. The project sponsor is the chief person who must be satisfied with the quality of the end product. Therefore, the project sponsor (also known as the business sponsor) is the one who should be involved in documenting the project objectives, identifying the risks, and establishing the priorities.
The project manager is responsible for the project once it has been evaluated and approved by the business. Therefore, in a way, the project manager's goal is more operational in nature than strategic.
3.4.3 Activities and Tasks in Business Evaluation
Figure 3.5 describes the activity-task mapping within the process-component of business evaluation. This activity-task mapping is also available on the accompanying CD for creating a project plan based on this mapping. The activities and tasks of this process-component play an important role in evaluating the business case and ensuring the project objectives within the business context.
)
Figure 3.5 Activities and tasks in business evaluation
3.4.4 Deliverables in Business Evaluation
Business case. The business case deliverable contains the arguments for why the project should go ahead. It also documents the cost-benefit analysis for the project. The scope of the project, its risks, and the related project estimates are all documented in the business case. This is the document presented to the steering committee.
Project brief. Typically, the project brief is a two-page document describing the project; it outlines the objectives of the project, the relevant project numbers, and the project schedule. The project manager and the quality manager are named in the project brief.
3.4.5 Quality Comments on Business Evaluation
Necessity
The business case should be carefully prepared to justify the need for a project. This document ensures that the purpose of the project is clear to all parties involved.
The project brief is the second mandatory part of this process-component, ensuring that the details of the project are succinctly summarized and available for reference throughout the project. The project brief also describes the type and size of the UML-based project.
The project sponsor is the main role in this process-component, ensuring that the business opportunities are properly analyzed and documented, and that the business proposal has considered all options.
The project formation is the starting point of the project manager's project responsibilities.
The activity of formulating the business proposal is crucial to the process-component of business evaluation. Results from this activity formally complete the deliverable of the business case.
The activity of project formation, through the tasks of the appointments of project manager and quality manager, literally forms the project.
Sufficiency
The project brief may not be produced in just one iteration. It will, perhaps, need to be updated based on the discussions during the steering committee approval. However, having the project brief deliverable provides the sufficiency, in terms of quality, in this process-component.
The steering committee also provides the criteria of sufficiency for this process-component. In small projects, the steering committee may play a notional role, but for medium and large projects, the committee brings in expertise from varying domains within the organization. The steering committee can also help to categorize the project into its respective type (for example, data warehousing, integration, or outsourcing). Having a steering committee for the project satisfies the sufficiency criteria of quality.
Business opportunity analysis provides the sufficiency in rigorously analyzing and questioning the need for the project.
Steering committee approval will easily iterate twice, if not more, before it provides sufficient rigor in deciding about the project. The steering committee members may ask the project sponsor to further investigate, collect, and collate the information—and only then will they approve the project.
3.4.6 Project Management Process-Component
The project management process-component deals with all activities and tasks that are carried out (primarily by the project manager) in managing the project. Project management is an extremely important process-component that includes understanding the technology, methodology, and sociology of the project. Therefore, this process-component interacts with the process-component of process configuration. The primary purpose of project management is to organize and track the project. Tracking involves risk management; therefore, project management also deals with risks and their prioritization. Project management provides feedback on the status of the project to various stakeholders including the user, the steering committee, and the project sponsor.
)
Figure 3.6 Process-component for project management
3.4.7 Roles in Project Management
The project manager is the primary role in this process-component of project management. This role is responsible for dealing with the activities of planning for the project, forming teams, launching the project, and continuously monitoring the risks.
The quality manager accompanies the project manager when performing her responsibilities but, at the same time, provides the independent crosscheck on the activities and tasks performed by the project manager.
The user continues to help the project manager by scoping the project, prioritizing the risks, and helping to minimize them.
3.4.8 Activities and Tasks in Project Management
Figure 3.7 shows the mapping of activities to tasks in the process-component of project management, which helps to create a good quality project plan and the management of the overall project.
)
Figure 3.7 Activities and tasks in project management
3.4.9 Deliverables in Project Management
Project plan (organizational). The organizational project plan provides the detailed description of the category and type of project, its resources, and its approach to quality.
Project task plan. The project task plan is a task list with corresponding resources assigned to it.
3.4.10 Quality Comments on Project Management
Necessity
The organizational project plan descriptively documents the planning process for the project. It is necessary to cross check its accuracy with the users, the project sponsors, and the steering committee.
The project task plan lists the tasks to be performed in the project and maps them to the corresponding resources. This is a necessary part of the process and requires an inspection to verify its quality.
The project manager, as the primary role in this process-component, should be checked for the correctness of the role description and the ability of the person playing this role to fulfill it.
The quality manager is necessary for the quality of the overall project. Creating a good quality environment is the responsibility of this role.
Project planning is a necessary part of the process-component, resulting in an organizational plan.
The activity of team formation should be checked to ensure that it provides all necessary guidelines in identifying team members and their formation into the right team. This is followed by ongoing management of the team.
Risk minimization and project tracking is an ongoing activity that is performed, in parallel, by all three major roles in this process-component. The project task plan is updated and fine-tuned with this activity.
Sufficiency
The organizational project plan should be updated with the soft issues related to team formation, to satisfy the criteria for sufficiency.
The user, another sufficiency criterion, is preferably onboard, as a part of the project team, to ensure the quality of project scope and risk minimization.
The quality manager not only performs the activities of environment creation and risk minimization as necessary, but also organizes and performs the quality tasks of inspection, walkthroughs, and reviews (described in the quality process-components), to ensure sufficient checking.
Project scoping is performed more than once to satisfy the sufficiency criteria.
Risk minimization, a responsibility of the user, will have to be performed to provide sufficient quality for the project.
Project launching is a formal activity in a large project, but may not be necessary in small projects.
3.4.11 Process Configuration Process-Component
Figure 3.8 shows the process-component of process configuration, which deals with understanding the process-related needs of the project, putting the process together, and later, enacting it in practice. If an organization is already process based, and the project is provided with a configured process to follow, then there is no need to undertake an extensive process survey. Initiating a process, customizing it, deploying it, and transitioning the people and the current style of working to the process style are critical for quality. Not only does this help to jump-start a situation where people working on the project do not spend or waste a lot of time deciding what to do, it also puts rules, standards, and templates in place that ensure the necessary steps within the process to produce the models in the various modeling spaces. Process configuration is also important in an iterative and implemental process because the need to identify the extent of iterations and the things that should be included in the increments are all important to the success of the quality of the project deliverables.
)
Figure 3.8 Process-component for process configuration
3.4.12 Roles in Process Configuration
The process engineer is the primary role in this process-component, responsible for the important activities of surveying the needs of a process within the project and creating a suitable SEP to satisfy it. It is not necessary for this role to be a permanent role in the project, because once the SEP is created by this role, the project manager is able to enact it. However, large process-conscious projects that need to handle the malleability of the process benefit by having this role on a long-term basis.
The project manager and the quality manager facilitate the work of the process engineer by providing the necessary needs of the process, and later deploying and enacting the process.
The project team has to understand and follow the process. They also have to provide feedback for the process, to enable its change and fine-tuning.
3.4.13 Activities and Tasks in Process Configuration
Figure 3.9 describes the activities and tasks of the process-component of process configuration.
)
Figure 3.9 Activities and tasks in process configuration
3.4.14 Deliverables in Process Configuration
The Quality Software Process is the repository of all process-components in the process. The QSP is configured to create an instance, which is the SEP to be followed in the project.
3.4.15 Quality Comments on Process Configuration
Necessity
The Quality Software Process with definitions of all process-components is the basic necessity of this process-component. The QSP itself is subject to quality checks, ensuring that it covers all areas of development.
The process engineer, also called the process consultant (due to the temporary nature of this role), is necessary for the process.
The quality manager focuses on the quality aspect of the process and the process aspect of quality—both of which are necessary for a good quality product.
Process creation is the activity of putting together a process, based on the process-components defined here.
Process deployment is sending the fully configured process out in the project, for use.
Sufficiency
The QSP is checked, rechecked, and brought to a level where it is acceptable to all stakeholders in the project, especially the project team.
The project manager provides the supporting role to the quality manager in organizing the process and ensuring it is the correct process for the project on hand.
Surveying the needs of a process is significant in a large, highceremony project.
The responsibilities of the process deployment, as handled by the project manager and quality manager, provide the sufficiency criteria to send the process out in the project.
Surveying the process needs by the process engineer is also part of a large, high-ceremony project. It is not necessary, in small projects, to undergo the detailed rigors of process surveys.
The project team must undergo sufficient training and should have the necessary buy-in, to derive the advantage of process deployment.
Process training is sufficient criteria, from the training processcomponent, to configure and deploy a process.
3.4.16 Requirements Modeling Process-Component
Figure 3.10 shows the requirement modeling process-component that deals with the actual capture, engineering, and analysis of the requirements of the business in the project. This process-component uses the primary mechanisms of use case modeling and activity diagramming to capture and document the problem that the business is trying to solve. Because quality is such a subjective phenomenon, it is absolutely crucial that those who will ascertain the quality (users and project sponsors) are involved as extensively as possible in this process-component.
)
Figure 3.10 Process-component for requirements modeling
The quality techniques of interviews and workshops are very helpful in executing this process-component. In addition to documenting the functional requirements in the problem space, this process component also encourages the user to provide the operational needs of the system. The user of the system or the businessperson who is involved in the project is ideally placed to provide the information on the expected volume, performance, and security needs of the system from an operational or nonfunctional viewpoint. This is all documented as a result of requirements modeling. Prototyping is also used in order to extract further requirements and refine the requirements already captured.
3.4.17 Roles in Requirements Modeling
The business analyst (also called the requirements modeler for most of this process-component) is the primary role here, and is responsible for understanding and documenting the requirements.
The domain expert and the user provide the information that the business analyst is trying to document.
The project manager, together with the quality manager, facilitates the process of requirements modeling. They also monitor and track the progress of the requirements-modeling exercise and report to the steering committee on this crucial process-component.
3.4.18 Activities and Tasks in Requirements Modeling
Figure 3.11 describes the activities and tasks of the process-component of requirements modeling. Refer to the accompanying CD for a tabular form of these activities and tasks to enable you to create your own customized project plan.
)
Figure 3.11 Activities and tasks in requirements modeling
3.4.19 Deliverables in Requirements Modeling
Functional specifications containing the use cases and activity diagrams that make up the model of the problem space are the main deliverables coming out of this process-component. Additional UML-based diagrams, namely the class diagrams, sequence diagrams, and state chart diagrams, also form part of the functional specifications. While a part of the model will usually be put in a CASE tool, some specifications (such as the use case documentation or the class responsibilities arrived at using the CRC techniques) may be outside the CASE tool.
Operational specifications document the requirements of the system when it goes out in operation. Therefore, these requirements are stored mostly in a document that describes the stress, volume, and performance requirements. Additionally, these requirements are provided using the deployment diagrams of the UML.
A glossary of business terms helps to record confusing or important terms. For example, terms like cover, policy, and insurance may mean the same thing for most people, but may have interpretation variations for the insurance domain modelers.
Functional prototype, as mentioned in the discussions on prototype, enables the extraction of complete and correct requirements.
3.4.20 Quality Comments on Requirements Modeling
Necessity
Functional specifications are a necessary deliverable of the process-component and should be produced iteratively with quality checks being applied to the diagrams inside them.
Operational specifications are an equally important and necessary part of this process-component. Without good quality operational specifications, the system may not succeed when it is deployed.
The business analyst is a necessary part of this process-component and must be checked for the accurateness of its role description and understanding of that description by the person performing the role. A business analyst is similar to the requirements modeler, except that the latter focuses only on creating the model (as opposed to the BA, who looks at the broader picture).
The domain expert and, more importantly, the user, are absolutely necessary in order to create a good requirements model. By participating in the MOPS creation process, they also firm up their own objectives and purposes for the project. This has a valuable quality connotation, as the user is eventually going to judge whether the product has quality or not.
The project manager, supported by the quality manager, provides the background organizational support for the process of requirements modeling.
Storyboarding is increasingly considered an important technique in discovering the correct and complete requirements with substantial participation from the user.
Domain analysis, particularly with the help of the domain ex- pert, provides a much broader view of the requirements—not limiting them to a single project. This is very valuable in a reuse program.
Use case modeling, by far the most revolutionary approach to requirements modeling, is primarily performed by the business analyst—with considerable input provided by the user/domain expert. This is a necessary activity and should be performed iteratively to produce a good suite of use cases and use case diagrams, together with the activity diagrams.
Requirements analysis is necessary to understand whatever has been documented in the use cases, and to extract correct business entities from that documentation in order to produce business class diagrams.
Business class modeling, also occasionally known as business domain modeling or business object modeling, is the creation of class diagrams at the business level, and should be checked as a necessary step in this process-component.
Instance modeling is necessary to correctly identify the way in which instances like objects on sequence diagrams or state charts behave. Documenting this behavioral aspect of this process-component is vital for quality MOPS.
Quality assurance of the entire MOPS, by conducting extensive inspections and reviews, is a necessary quality check, and should be performed following the quality techniques described in Chapter 6.
Sufficiency
The glossary of business terms is very helpful, if produced in a project where the team members are new to the domain.
A functional prototype, although not necessary for every project, is sufficient for a good quality requirements modeling exercise.
The roles of business analyst and requirements modeler should also undergo process sufficiency checks to ensure that they are properly defined, are staffed in the right numbers, and have sufficient understanding of the uncertainties around this process-component.
Context modeling, through the use of case diagrams at an abstract level with a boundary and activity diagrams at an abstract level, can provide the context of the system. Performing this activity satisfies the sufficiency criteria of quality.
Operational analysis should be performed with sufficient depth—otherwise, the operational specifications will end up getting produced through the other activities of domain analysis and use case modeling—not an ideal situation.
The business class modeling should be iterated sufficiently before a good class model at business level emerges.
Project tracking, an ongoing activity, satisfies the sufficiency criteria of a quality process.
Measurements and metrics provide the additional benefits of process maturity to a project, if desired.
3.4.21 Interface Modeling and Design Process-Component
The process-component of interface modeling provides guidance for modeling and designing the important interface aspect in a system—the GUI, printing interface, and interfaces to other devices. The GUI and printer interfaces are essential, not only for the performance of the system, but also for the way it is perceived by the users. In all e-business applications, this particular process-component takes an even more crucial role. It is not enough to provide just a good-looking interface; it should be designed as a system on its own—with sufficient discussion and modeling on the navigational aspects of the interface. Availability of the interfaces across geographical and time boundaries is vital. Issues of language and notation (as in Chinese, Hindi, or French and corresponding cultural notations) relating to widely dispersed user groups are important in Web interfaces. Furthermore, providing feedback to the user through legible messages, sound, and related mechanisms is vital for a good user interface. Thus, the interface modeling process-component should encompass prototyping, navigation diagrams, site maps, sketching, play acting, and other appropriate techniques to create a quality-conscious interface.
)
Figure 3.12 Process-component for interface modeling and design
3.4.22 Roles in Interface Modeling
The user interface (UI) modeler and the business analyst play the primary roles in this process-component; the BA specifies the requirements of the interface and the UI modeler designs it.
The involvement of the user in interface modeling and design is of interest both to the user and the UI modelers. Quality perception is positively affected by the involvement of the user in this process-component.
The role of quality manager facilitates the activities and tasks within the process-component.
3.4.23 Activities and Tasks in Interface Modeling
Figure 3.13 describes the activities and tasks of the process-component of interface modeling. Refer to the accompanying CD for a tabular form of these activities and tasks to enable you to create your own customized project plan.
)
Figure 3.13 Activities and tasks in interface modeling and design
3.4.24 Deliverables in Interface Modeling
Interface specifications document the requirements of the interface and are mainly driven by the needs and desires of the user.
Interface design is a deliverable containing details of the design that implement the GUI. It contains solution-level class diagrams that also include reusable user interface libraries and so forth.
Functional prototype (interface) optionally adds value to the interface specifications and designs in this process-component.
3.4.25 Quality Comments on Interface Modeling
Necessity
Interface specifications are a necessary part of this process-component. The quality of the final interface depends on specifying, in detail, what users want and how they want it. Therefore, this specification document relates to the use case specifications, associated use case diagrams, and activity diagrams.
Interface design is a deliverable produced in the solution space. It is the design of the interface and a system on its own. Therefore, it contains all the necessary checks for a good design, including checking the class diagrams that mainly have their stereotypes as interface or boundary.
The user interface modeler and the business analyst are necessary parts of this process-component and should be checked for their understanding of the requirements from the user's viewpoint. Therefore, a good BA and a good UI modeler work iteratively, by showing the interface progressively to the user and getting their feedback before proceeding with more designs.
Interface specifications are necessary before a good design can be produced. They are also checked for their ability to satisfy the requirements described in the use cases.
Interface designing is the activity that ensures that the results of the interface specification activity are taken down close to low-level design, wherein they can be easily implemented.
Sufficiency
The functional prototype provides additional criteria for quality, as it enables better documentation of the interface.
The interface design is also sufficiency criteria. It is possible to jump directly from interface specifications straight to implementation, but it's not advisable. Therefore, the interface design is provided as sufficiency criteria, as well.
The user should be sufficiently involved in the interface specifications by analyzing the interface requirements.
The business analyst, in particular, provides the quality criteria for sufficiency by providing the link between the modeling done by the UI modeler and relating it to the user.
The quality manager is involved in this process-component by providing sufficient support and coordination—especially when usability inspections are formally conducted.
Interface requirements analysis provides the background to perform the user stories, the use cases, and the functional prototypes, in order to understand the interface requirements fully before designing them.
Usability inspections are along the lines of Constantine's Collaborative Usability Inspections (CUIs) and provide a formal review of interface quality, in the presence of the user and the developers.
3.4.26 System Design Process-Component
The process-component for system design produces the system design deliverable. The system design deliverable has the low-level designs that contain classes and class definitions that deal with the language of implementation and the databases. Solution-level design includes solution-level class modeling and instance modeling.
)
Figure 3.14 Process-component for system design
3.4.27 Roles in System Design
The system designer is the main role in this process-component. The system designer must have enough information about the implementation language and the environment for implementation to perform this role successfully. Quality in this process-component comes not only from the experience of the designer but also from his/her technological knowledge.
The programmer continues to assist the system designer, checking on the feasibility of the designs by trying them out in code.
Project manager/quality manager
3.4.28 Activities and Tasks in System Design
Figure 3.15 describes the activities and tasks of the process-component of system design. Refer to the accompanying CD for a tabular form of these activities and tasks to enable you to create your own customized project plan.
)
Figure 3.15 Activities and tasks in system design
3.4.29 Deliverables in System Design
The system design contains the details of the technical design that form part of MOSS.
The prototype (technical) is a code-level prototype that helps when trying out a few code examples.
The pattern libraries may be directly inserted in the system designs or may be newly created for local project or organizational-level patterns.
The legacy interfaces (especially in integration projects) are considered at the design level. We think of all the necessary issues of implementation, including legacy interfaces, before a system can be fully implemented.
The reuse plan (input), if produced, provides the background support for reuse in the designs.
3.4.30 Quality Comments on System Design
Necessity
System design is a necessary part of the system design process-component and should undergo the quality checks using the techniques of interviews and reviews in workshop format.
Using the pattern library, or at least giving patterns serious consideration, is necessary for good quality.
The system designer is the primary owner of this process-component. The role should be well-defined and understood by the person performing it.
-
Business class analysis requires understanding the class diagrams drawn by the BA in the requirements modeling process-component. Therefore, this is a necessary starting point for any work that takes place in the design.
Advanced class design, as shown in Chapter 4, is necessary for this process-component. It deals with creating classes that are very close to implementation.
Advanced instance design is a necessary step in system design because the sequence and state chart diagrams ensure that the classes drawn in the class diagrams are complete and correct. This is done by cross checking the sequence and state chart diagrams with the classes in the class diagrams.
The coding activity provides the necessary support for creating the prototype and verifying the designs. It may be undertaken quickly by the system designer herself.
Sufficiency
Check the availability of a reuse plan and incorporate the suggestions and standards from the plan into the design.
Check to determine if the technical prototype is necessary—it should be created to test out the validity of the designs and will satisfy the sufficiency criteria.
Pattern libraries should also be sufficiently considered in the system designs.
Legacy interfaces, for a legacy integration project, are created to satisfy the sufficiency criteria.
The programmer, if available, is sufficient for the quality system designs. If not, the cursory programming work is carried out by a system designer.
The project manager/quality manager provides the background support and coordination activities.
Coding may be attempted a few times, in creating prototypes, reusing libraries, or simply creating earlier cuts of the code.
Project tracking is an ongoing activity, which may be undertaken at the completion of major activities in this process-component.
Quality assurance of MOSS will have to be performed a few times, iteratively, to satisfy the sufficiency requirements of the project.
3.4.31 Persistence Design Process-Component
Persistence design, another term to describe database design, is treated as a separate process-component because of its importance—not only in storing standard relational data, but also in storing a variety of content in today's Web applications. The need to interface with existing legacy systems, store and massage audio and video contents, convert data, and provide reuse and multidimensional drilling into the data are some of the reasons database design is important and is treated as a separate process-component.
While using the capabilities of the UML to represent the databases in class diagrams, it is also important to use sequence diagramming techniques in order to document the access to the databases, the security to the databases, and the consistency requirements. Prototyping from an operational viewpoint can also provide valuable information during the database-design phase.
)
Figure 3.16 Process-component for persistence design
3.4.32 Roles in Persistence Design
The database designer/manager creates database schemas, strategies for conversions, and population of data.
The quality manager facilitates the environment for the creation of the databases and ensures the quality of the schemas created. Thoughts are also given to the population of the databases, especially if data is to be converted from an existing system.
The system architect provides operational input.
3.4.33 Activities and Tasks in Persistence Design
Figure 3.17 describes the activities and tasks of the process-component of persistence design. Refer to the accompanying CD for a tabular form of these activities and tasks to enable you to create your own customized project plan.
)
Figure 3.17 Activities and tasks in persistence design
3.4.34 Deliverables in Persistence Design
- Database design
- Conversion plan
- Prototype (technical)
3.4.35 Quality Comments on Persistence Design
Necessity
Create the database design based on the persistent classes from the MOSS class diagrams.
Ensure that the person playing the role of the database designer understands both the UML modeling techniques and the capabilities of the database in implementation. Conversion requires additional skills in understanding the structure of the existing database.
Class mappings require mapping the class diagrams in the solution space to the database tables. Relationships between classes in the class diagrams are translated to relationships between database tables using the primary and foreign keys of relational database designs. Multiplicities also provide additional and valuable information.
Database interfaces include interfaces to front-end Web inter- faces (using, say, the XML), or back-end legacy interfaces. Prototypes are created to investigate these interfaces and produce designs.
Design verification is a formal activity, following the review techniques, to ensure the consistency of the new database schema.
Sufficiency
A conversion plan is required only when data has to be converted into the new system. Alternatively, for a Web application, contents might be required.
Prototypes provide sufficient details in creating a good database design—not only from the structural viewpoint, but also from the population and performance viewpoints.
The quality manager provides the organizational support and applies the quality techniques of inspections, reviews, and workshops to the designs.
The system architect ensures that the database design is in accordance with the overall system architecture.
Class mapping has to be double-checked for sufficient compatibility of the classes and the corresponding relational tables.
Normalization may be attempted in practice and will be influenced by the multiplicities in the class diagrams.
Data verification follows some of the testing techniques of equivalence partitioning and boundary value (as discussed in Chapter 6).
System architecture appraisal ensures that the database design does not transgress the architecture of the system (for example, the bandwidth limitations of the architecture will influence the database design).
3.4.36 Implementation Process-Component
The process-component for implementation deals with coding. While all other process-components deal with understanding the problem in managing the project, this one deals extensively with implementation of the models using the available technology. Thus, the designs created during the system design, database design, and interface modeling are implemented during enactment of this process-component. Implementation deals with understanding both the requirement models and the designs.
Before creating the actual code it is necessary to incorporate the reusable libraries (already done in the system design process-component). This is followed by creating the implementation classes and compiling, linking, building, and testing them. Testing includes the creation of test harnesses within the code itself, as well as conducting unit tests and stepping through the created code. Occasionally, if processes like eXtreme Programming are followed in the project, the results from the implementation effort can be immediately showed to the users with a very short turnaround time.
3.4.37 Roles in Implementation
-
The programmer implements the designs iteratively. Many people play this role in a project; they interact with each other in the roles of programmer and, when the need arises, with other roles such as system designer and business analyst.
-
The system designer supports the programmer by explaining the designs created in the MOSS.
- The business analyst supports the programmer by ensuring that the requirements are properly understood and met.
)
Figure 3.18 Process-component for implementation
3.4.38 Activities and Tasks in Implementation
Figure 3.19 describes the activities and tasks of the process-component of implementation. Refer to the accompanying CD for a tabular form of these activities and tasks to enable you to create your own customized project plan.
)
Figure 3.19 Activities and tasks in implementation
3.4.39 Deliverables in Implementation
The code (executable) is the final software deliverable resulting from the modeling effort. This executable may not be a single file; it may be comprised of a number of executables spread over the system architecture.
Reusable libraries (components and packages). In addition to the final code produced, there should be a provision, in a good process, to produce and store reusable components for future use. This reusable library deliverable enables the creation and storage of reusable code, typically made up of components and packages.
3.4.40 Quality Comments on Implementation
Necessity
Executable code, including dynamic libraries, is the primary product of this process-component. While this is produced iteratively, eventually it is the product deployed. In outsourced projects, this deliverable is produced by an external (outsourcing) organization.
The reusable library deliverable is almost an integral part of code production because it can be termed an interim deliverable before the final product is produced. This is because most object-oriented/component-based systems are not built as systems but, rather, as reusable components, which are then assembled to create the product.
The programmer is at the core of this process-component. Her profile, job description, skills, and experience should be well coordinated and a match with the project technology. Furthermore, it is vital that the programmer is able to converse with the system designer to determine that the designs are properly understood. In a small project this role may merge with the design role.
Coding is the primary activity of this role. It is performed by the programmer in an iterative and incremental manner. This activity requires that the programmer writes classes, tests harnesses, conducts unit tests, and updates the reusable class libraries with the created components.
As required by most programming environments, the activity of coding is followed by the detailed activity of building the software. This requires the programmer to integrate the code written with associated libraries in order to make it runnable.
Having written the code and built the executable, it is necessary for the resultant module within the product to be tested in detail. This testing ensures that the testing progresses incrementally from component to system to integration tests. Incremental testing implies creating a component and testing it first. This is followed by creating another component (perhaps by another programmer) and testing it. Once the second component is created, it may be necessary to test them together. Once a significant number of components are created, they will have to be integrated with other systems (for example, legacy systems). Thus, the incremental creation and addition of components to the system is what is described in the testing activity.
Sufficiency
Reusable class libraries need additional checks in terms of generalization of code. When the classes and components are created, they need to be generalized incrementally. This generalization may happen in the second or third iteration of the current development, or in subsequent projects.
The system designer provides the sufficiency of process by supporting the programmer. The necessary aspect of the system designer role is discussed in the system design process-component. Here, he is supporting the programmer, thereby satisfying the sufficiency criteria in the process.
The business analyst, similar to the system designer, provides the sufficiency aspect of the process by supporting the programmer in explaining the requirements on a "need to know" basis.
The activity of system design appraisal provides information to the programmer on the languages and middleware recommended by the system designer. Optionally, the activity of coding influences the system design as well.
Similar to the influence of system design on coding and vice versa, there is influence of the architecture on coding and vice versa. This means the architectural decisions taken in the system architecture process-component provide the boundaries for coding.
The requirement model's appraisal may also be necessary, optionally, for the programmer who is trying to understand and keep in mind the use cases at the highest level. Although the activity of coding is driven by class diagrams in the MOSS, the influence of requirements should be considered, wherever relevant.
Environment creation, if treated separately, ensures that the development environment is given its due and separate importance. For small projects, however, it may not be necessary to treat this separately, and the activity may be performed by the programmer as a part of coding.
3.4.41 Prototyping Process-Component
The process-component for prototyping combines skills of requirements modeling, system designing, and programming in order to create prototypes; it also benefits the creation of models in the problem, solution, and background spaces. Since this process-component for prototyping enhances the quality of all other deliverables, prototyping does not stand on its own. I have treated prototyping as a separate process-component because of the need to understand it on its own before using it to improve the quality of deliverables in the other process-components.
)
Figure 3.20 Process-component for prototyping
While prototypes enhance the overall quality of the system, they themselves should adhere to some quality requirements. For example, prototypes should not give the wrong impression of what can be achieved. This happens most commonly when a highly sophisticated prototype is produced in order to gain project approval; the implementation may not be able to sustain the promises of the prototypes.
In most practical software projects, the process-component for prototyping potentially produces three prototypes:
The first deals with the functional needs of the users, which includes the needs for the interface, navigation, and overall functionality.
The second deals with the selected technology and its suitability, such as languages, language compilers, reusable libraries, and databases.
The third one is the architectural prototype, which deals with issues of security and performance. This architectural prototype also experiments with technologies such as Web application servers, e-services, and mobile services, to consider their appropriateness in the project or the overall organization. Therefore, in addition to the knowledge of the languages and databases, there is also a need to understand the overall environment for implementation.
3.4.42 Roles in Prototyping
Prototyper (programmer, business analyst, system architect)
User/project sponsor
Project manager/quality manager
3.4.43 Activities and Tasks in Prototyping
Figure 3.21 describes the activities and tasks of the process-component of prototyping. Refer to the accompanying CD for a tabular form of these activities and tasks to enable you to create your own customized project plan.
)
Figure 3.21 Activities and tasks in prototyping
3.4.44 Deliverables in Prototyping
Prototype (functional)
Prototype (interface)
Prototype (technical)
Prototype (architectural)
3.4.45 Quality Comments on Prototyping
Necessity
-
The functional prototype is a necessary aspect of any process because it helps set and manage expectations of users and business sponsors.
-
The interface prototype is usually a GUI prototype that may be produced along with the functional prototypes. It provides the "look and feel" of the system and should be attempted after at least some part of the functionality is clear. Otherwise, there is a risk that the functional requirements will be sidestepped for discussions related to the interface.
-
The technical prototype provides information to the system designer and the data modeler on the capabilities of the solution. It is important that this prototype is produced, however briefly, before the actual solution is implemented.
-
The architectural prototype provides information related to the architectural capabilities that already exist in the organization, its limitation, and how the system architecture fits with the overall enterprise architecture. For large projects, information and security architecture have separate influence and, therefore, benefit by creation of a prototype.
-
The role of a prototyper can be played by any of the other roles shown in Figure 3.20, depending on the type of prototype being created.
-
Functional prototype creation provides the necessary input into the requirements modeling exercise. However, this may not be an executable prototype.
-
Technical prototype creation usually has an executable that tests the capability of the technologies in providing the solution; it relates to the operational requirements.
-
Architectural prototype creation also relates to the operational requirements.
)
Figure 3.22 Process-component for change management
Sufficiency
The functional prototype needs to be iterated and checked more than once in order to reach a satisfactory level of acceptance. Because of the importance of the functional prototype in the project—especially in reducing misunderstandings between users and developers—this prototype should be carefully created and agreed upon for sufficient quality.
Prototyper is not just one person playing one role but, perhaps, more than one person playing multiple roles. While a prototyper is necessary in this process-component, it is the variation to this role that satisfies the sufficiency criteria.
The user or project sponsor provides sufficient depth to the prototyping exercise by providing detailed feedback to the prototypers on their requirements, as well as getting a good understanding of their own expectations.
The project manager or quality manager also provides the additional support in understanding the user expectations correctly.
Providing feedback is an activity that enables the prototypers to understand their own prototypes and iteratively improve them to enable the users to express their needs correctly.
Purpose identification helps to focus on the purpose of the prototype. It is only when the question "Why are we creating this prototype?" is answered that the prototyper can be comfortable with his work.
While a prototype is created for numerous purposes, setting the expectations of the users is one of the most important aims of prototype creation. This check provides the sufficiency criteria of rightly setting the expectations of the users.
3.4.46 Change Management Process-Component
The process-component for change management supports all the changes that occur in the project. In addition to the sociological aspect of change, this process-component also deals with the critical job of providing support for the configuration and version management needs of the project. Versioning and version release is important in an IIP process. This is where the configuration management part of change management helps to put together the product releases. Therefore, this process-component is closely associated with that of process configuration and project management. Once an item such as a UML model or a class has reached a stable situation it should be placed under the change management process-component.
3.4.47 Roles in Change Management
Project team
Project manager
Quality manager
3.4.48 Activities and Tasks in Change Management
Figure 3.23 describes the activities and tasks of the process-component of change management. Refer to the accompanying CD for a tabular form of these activities and tasks to enable you to create your own customized project plan.
)
Figure 3.23 Activities and tasks in configuration management
3.4.49 Deliverables in Change Management
Version control plan deals particularly with the software product version control. This is either a separate deliverable or part of the change management plan.
Upgrade/release strategy is the end result of the effort made in change management. It deals in general with any upgrade to the software, environment, or teams. In particular, though, it deals with upgrades to the software models and products.
3.4.50 Quality Comments on Change Management
Necessity
The version control plan deals with the versioning of software releases. This is a necessary part of a good process because this plan decides on the version numbering and deployment of the software product.
Upgrade/release strategy is the result of the activities in change management. While mostly it affects a software model or product, this upgrade/release strategy can also be a change in team structure, organizational structure, and so on.
The project manager effectuates the change.
The project team undergoes the change in most cases.
The software model's change management will likely be the most important aspect of change management.
Version management ensures that the changes and upgrades brought about in the software are appropriately released in the user community.
Sufficiency
The quality manager provides additional support to the project manager in bringing about the changes. In some cases, though, the quality manager herself may bring about the change.
Process change management provides sufficiency in terms of process steps when change is brought about.
Social change management is usually associated with product change management, although the way in which it is dealt with is different from the product change management approach.
Process change management is supported by the quality manager.
Social change management is supported by the quality manager.
3.4.51 Enterprise Architecture Process-Component
The enterprise architecture (EA) process-component deals with the overall enterprise modeling and ensures that the system produced as a result of the project under consideration is able to operate with the existing systems of the enterprise. At a project level the activity of creating the enterprise architecture is limited, but ensuring that the system architecture conforms to the EA (resulting potentially in an EA Integration) is high.
)
Figure 3.24 Process-component for enterprise architecture
3.4.52 Roles in Enterprise Architecture
System architect provides expertise and experience in producing a good, robust enterprise architecture.
Project team interacts with the architect to ascertain the mechanism to implement the architecture and highlights the possible limitations of the existing technical environment.
Project manager/quality manager organizes and manages the creation of the enterprise architecture.
3.4.53 Activities and Tasks in Enterprise Architecture
Figure 3.25 describes the activities and tasks of the process-component of enterprise architecture. Refer to the accompanying CD for a tabular form of these activities and tasks to enable you to create your own customized project plan.
)
Figure 3.25 Activities and tasks in enterprise architecture
3.4.54 Deliverables in Enterprise Architecture
Enterprise architecture is made up of the actual enterprisewide architecture and the document that outlines that architecture.
System architecture is produced during the system architecture process-component and embellished here. Alternatively, creation of the initial system architecture may start here, followed by its rigorous upgrade in the system architecture process-component.
3.4.55 Quality Comments on Enterprise Architecture
Necessity
A primary necessity check ensures that the system architecture is iteratively cross checked against the enterprise architecture. This results in compliance of the system architecture with the enterprise architecture.
In most projects, the opportunity to create enterprise architecture is limited. However, each project influences the overall architecture of the enterprise, and may incite rethinking on the part of the architects in terms of, say, bandwidth requirements or database capacity.
The system architect is the primary role in this process-component, in terms of checking the influence of enterprise architecture on the system architecture. When decisions related to the enterprise and all its related systems and architecture are to be made, the role of system architect may be played by a senior technical person well versed in the enterprise architecture. The system architect ensures that the architecture of the system conforms to the enterprise architecture.
Architectural surveying deals with understanding the existing enterprise architecture to ensure that the system architecture is created within the bounds of the enterprise architecture. Operational requirements are also considered in surveying the overall architectural needs.
It is important to perform the activity of enterprise architecture checking while keeping in mind its potential effect on the project and the quality management aspect of the project.
Sufficiency
With the advent of Web-based solutions in almost all modern- day projects, it is important to consider the Web application architecture in overall enterprise architecture. Web architectures have the ability to influence, and many times change, the manner in which solutions are provided.
Reuse strategy is important at the enterprise level in terms of its influence on creating architecture versus buying middleware and Web architectures off the shelf. The reuse strategy influences the system architecture as well.
Some senior project team members will be involved in the creation of part of the enterprise architecture. Other team members should be aware of the enterprise architecture.
The project manager and the quality manager play supporting roles in ensuring that the enterprise architecture is cross checked against the architecture of the system. The project manager is involved, in particular, when there is a conflict between the system, enterprise architecture, and the ramification of this conflict on project cost and time estimates.
Creation of enterprise architecture is not a singular activity with a set completion time. Instead, enterprise architecture is created based on a number of projects, with each project improving and adding to the existing architecture. Sometimes, though, when not only the software system is newly built, but also the organization itself is new, there will be an opportunity to create completely new enterprise architecture. While the system architect is primarily responsible for this enterprise creation, the project team also joins in discussing and understanding the architecture.
Enterprise architecture is checked for its completeness and consistency by the system architect. The project manager and the quality manager must facilitate this checking and will have to be fully aware of it as the project progresses.
3.4.56 System Architecture Process-Component
System architecture deals with the architectural work in the background that ensures that the requirements and the designs are in accordance with the overall needs and availabilities of the project. The activities and tasks in the system architecture process-component take a "bird's-eye" view of the requirements and design, ensuring the consistency and completeness of the MOBS.
Figure 3.26 Process-component for system architecture
3.4.57 Roles in System Architecture
System architect
System designer
Project manager/quality manager
3.4.58 Activities and Tasks in System Architecture
Figure 3.27 describes the activities and tasks of the process-component of system architecture. Refer to the accompanying CD for a tabular form of these activities and tasks to enable you to create your own customized project plan.
)
Figure 3.27 Activities and tasks in system architecture
3.4.59 Deliverables in System Architecture
System architecture (solution architecture).
Reuse strategy. As seen in the system architecture process-component diagram, the reuse strategy facilitates the incorporation of reusable architectures and designs in the architecture of the current system.
Prototype architecture also provides valuable input into the system architecture.
3.4.60 Quality Comments on System Architecture
Necessity
System architecture is the main deliverable of this process-component. It is either a document outlining the architecture of the system or, especially in large projects, a suite of libraries and patterns on which the actual system is built.
The system architect plays the primary role of creating the system architecture.
Architectural surveying is an activity that takes stock of the existing enterprise architecture before relating it to the system architecture.
The creation of a system architecture deals with information, network, and database architectures, to name but a few. This activity results in the system architecture mentioned in step 1 above.
Operational requirements confirmation ensures that all operational requirements are formally incorporated in the system architecture. While other activities in this process-component continue to take input from the operational requirements, this specific activity is intensely focused on ensuring that the system architecture can handle the operational requirements.
Sufficiency
Reuse strategy is an iteratively produced deliverable that is updated even during the enterprise architecture process-component. Here, in system architecture, the reuse strategy provides valuable and sufficient input to enable the reuse of patterns and designs.
Architectural prototype, created in the prototyping process-component, is used here to help create and verify the system architecture.
The system designer plays the supporting role to the system architect in verifying the implementability of the system architecture.
The project manager/quality manager also plays the supporting role in facilitating the creation and verification of the system architecture.
The pattern incorporation activity provides sufficient depth to the system architectural work by enabling identification, experimentation, and adoption of known patterns. These known patterns are not restricted to published patterns. They can also include patterns that were discovered and documented in previous projects within the organization.
3.4.61 Deployment Process-Component
See figure 3.28.
)
Figure 3.28 Process-component for deployment
3.4.62 Roles in Deployment
The project manager organizes the deployment and release of the product after taking input from the change management process-component.
The project team participates in deployment and post-deployment reviews.
The user is involved in ensuring that the deployment of the system is smooth, especially from the sociological angle.
3.4.63 Activities and Tasks in Deployment
Figure 3.29 describes the activities and tasks of the process-component of deployment. Refer to the accompanying CD for a tabular form of these activities and tasks to enable you to create your own customized project plan.
)
Figure 3.29 Activities and tasks in deployment
3.4.64 Deliverables in Deployment
The deployment plan deals with the strategies of sending the product out in the real world. This deployment plan also deals with issues related to switching the business over from one product to another. It may be a part of the overall project plan.
The released product is the final software product that is released to the users.
The operational plan provides important information in deployment, as it contains details of the system's requirements when it goes out in operation.
3.4.65 Quality Comments on Deployment
Necessity
It is necessary to ensure that the deployment plan is in accordance with the expectations of the users. This plan must consider the issues of new deployment as well as of switching over, when a replacement product is introduced. It is also necessary to consider supporting materials such as help and user manuals and initial training to support the product being deployed.
Check that the released product is in a fully deployable format. This means that not only is the product fully tested in the development environment, but it is also litmus-tested in the production environment before being deployed.
The project manager is in a continuous coordination role in this process-component.
Product packaging is important in cases where the product is released in physical forms such as CDs and Zip disks. In these cases, packaging of the product, its associated licensing, and so on, is crucial.
This is the activity of actually releasing the product to the users.
Sufficiency
Check the operational plan for additional information on the system in terms of its operations. For example, backups and mirroring are common requirements of a system in operation and should be specified and adhered to for the system to be of good quality in operation.
The user representative facilitates deployment of the system, especially socially, wherein it is made acceptable and promoted within the larger user community.
The project team is involved in getting the product ready for release. While there will be very little programming or design-related activities here, the technical aspect of the deployment is still critical and is handled by the project team.
Release assimilation becomes important in cases where the product has to be physically sent to the users or when the product is packaged and put on shelves for sale (for example, shrink-wrapped software).
-
Release timing provides for the sufficiency of release by ensuring that the release is properly coordinated. This becomes important when a new module or system is released to replace an existing system that is working on a 24 x 7 basis (online and available all the time).
Post-testing verification ensures that the integration and acceptance testing is complete and that the users are ready to accept the system.
3.4.66 Training Process-Component3.4.67 Roles in Training
-
Training manager, who organizes the training. This role may be played by the project manager or a member of the project team.
-
Project team plays a dual role here. Initially, the project team needs technical and other related training. Later, during the deployment of the product, this team is also responsible for creation of a training mechanism for the user. Selected members from the project team can be made responsible for creation of appropriate training packages. User representatives on the project can provide invaluable assistance in creating such training packages.
- Users, who will undergo training and learn to use the system effectively.
)
Figure 3.30 Process-component for training
3.4.67 Roles in Training
-
Training manager, who organizes the training. This role may be
played by the project manager or a member of the project team. -
Project team plays a dual role here. Initially, the project team needs
technical and other related training. Later, during the deployment of
the product, this team is also responsible for creation of a training
mechanism for the user. Selected members from the project team can
be made responsible for creation of appropriate training packages.
User representatives on the project can provide invaluable assistance
in creating such training packages. Users, who will undergo training and learn to use the system effectively.
3.4.68 Activities and Tasks in Training
Figure 3.31 describes the activities and tasks of the process-component in training. Refer to the accompanying CD for a tabular form of these activities and tasks to enable you to create your own customized project plan.
)
Figure 3.31 Activities and tasks in training
3.4.69 Deliverables in Training
The training plan contains descriptions of what type of training is required, who are the target participants of the training, and most importantly, when the training is conducted.
The training materials are the handouts or other accompanying materials provided to the participants of a training course. This training material need not be printed paper only, as it is common to have CDs and videos accompanying training courses. These additional tools containing training materials are especially helpful in conducting user training in the software product delivered.
3.4.70 Quality Comments on Training
Necessity
The training material is the prime material accompanying a training course. This step ensures that such material is readily available and is provided in a format acceptable to the users.
The training manager should be fully aware of the training needs of the organization, the suppliers of the training needs, and the timing of the training. In small projects the project manager may also play this role; large projects will greatly benefit if this responsibility is assigned to a separate individual.
Users will have to be trained not only in the use of the new system but also in the altered business procedures as a result of the new system.
The project team undergoes training depending on its skill levels and needs. In a large project, it is important to train the team in relevant modeling (UML) and processes early. The project team will also deliver relevant training on their product to the user.
Assessing the training needs of all players in the project should be done carefully to ensure that the training relates to the needs of the trainees. It is also important to ensure the support of the management by referring to the training plan.
Software product training is undertaken to enable the user to start using the system.
IT training is aimed at the project team to equip them with their needs for modeling, process, and technical skills.
Sufficiency
The training plan is part of the overall project plan, and describes the training needs of the project. This includes a range of training needs from technical training to be provided to the technical team through end user training on the software product.
Business process training ensures that the users are able to carry out the changes in conducting business.
Call center training is required if the new system requires the organization to provide that support.
3.4.71 Reuse Process-Component
The process-component for reuse provides the crucial background set of activities and tasks that actively encourage reuse at all levels within the project. This includes not only the well-known code level reuse (through classes and components in the domain of object technology) but also includes the reuse of requirements, architecture, design, and testing.
)
Figure 3.32 Process-component for reuse
3.4.72 Roles in Reuse
System architect, who knows enough about the overall technical environment to facilitate both creation and consumption of reusable components.
System designer/business analyst/programmer
Project manager/quality manager
3.4.73 Activities and Tasks in Reuse
Figure 3.33 describes the activities and tasks of the process-component in reuse. Refer to the accompanying CD for a tabular form of these activities and tasks to enable you to create your own customized project plan.
)
Figure 3.33 Activities and tasks in reuse
3.4.74 Deliverables in Reuse
The reuse plan helps to organize the process-component of reuse within the project.
Reusable entities (consumed) are models and documentation of reusable components that have been inserted in the architecture and the software design within the current project.
Reusable entities (produced) are models and documentation of potential reuse components produced by this project for future use.
3.4.75 Quality Comments on Reuse
Necessity
Reusable entities are produced by the project.
The reuse plan iteratively provides input into enabling reuse opportunity identification.
The system architect provides necessary support in terms of enabling reuse strategies by identifying opportunities for reuse and actually reusing the architectural aspects of the system.
The system designer, business analyst, and programmer are involved in their respective aspects of reuse.
Reuse opportunity identification is an activity carried out by people of relevant roles.
Requirement reuse is important and is easily facilitated by the UML's use case-based approach.
Design reuse is also facilitated by the object-oriented aspect of the UML and, in particular, design patterns and class diagrams. It is important to note that both production and consumption of reuse is encouraged in design reuse.
Code reuse is well known and the first attempt at reuse by the software community.
Sufficiency
Reusable entities consumed by the new projects provide for the sufficiency aspect of reuse.
Patterns—both published and internally created—are crucial for analysis- and design-level reuse in any project.
Reuse opportunity identification is additionally carried out by the system architect.
Architectural reuse enables reuse of Web application servers and other middleware-type architectures.
The project manager and quality manager facilitate reuse and work on the reward structures supporting reuse.
Reuse support deals with the managerial activities of rewarding reuse and also promoting the policy of "reuse rather than build."