Modeling with SDLC, OO, B.O.O.M

Slide #4

The names of the phases differ from SDLC to SDLC, but most SDLCs have something close to the following phases:

• Initiation: Make the business case for the project. Work also begins on the user experience and on drafts of architectural proof of concepts. The prototyping effort during the Initiation phase should be risk-driven and limited to gaining confidence that a solution is possible.
• Discovery: Conduct investigation leading to an understanding of the solution's desired behavior. (On iterative projects, requirements analysis peaks during this phase but never disappears entirely.) During this phase, architectural proofs of concept are also constructed.
• Construction: Complete the analysis and design, code, integrate, and test the software. (On iterative projects, these activities are performed for each iteration within the phase. Design and coding appear in all phases, but peak during this phase.)
• Final Verification and Validation (V&V): Perform final testing before the product or service is transitioned into production. (While final testing occurs in this phase, testing activities may occur throughout the SDLC—for example, before design or as a replacement for it.)
• Closeout: Manage and coordinate deployment into production and close the IT project.

Slide #5

The objectives of the Initiation phase are to develop the business case for the project, establish project and product scope, and explore solutions, including the preliminary architecture. The PM assists the project manager by identifying stakeholders, business services and processes, and IT services affected by the project. By the end of this phase, key functionality is identified, such as key system use cases (user tasks) and IT services. When a non-agile process is used, these requirements are baselined and subsequent changes to scope are managed in a controlled manner using a change-management process.

The Initiation phase poses a conundrum for the PM. The purpose of this phase is to get a rough cut at the business case for a proposed IT project. The trouble is that without knowing the requirements, it's impossible to estimate the cost of the project; at the same time, without a business justification for the project, it is difficult to justify much requirement analysis. The answer is to do just enough research to be able to create a ballpark estimate. You'll do this using a number of UML techniques that keep you focused on high-level needs. These techniques are as follows:

• Business use cases: A tool for identifying and describing end-to-end business processes affected by the project.
• Activity diagrams: Used to help you and stakeholders form a consensus regarding the workflow of each business use case.
• Actors: These describe the users and external systems that will interact with the proposed IT system.
• System use cases: Used to help stakeholders break out the end-to-end business processes into meaningful interactions with the IT system.

By the end of this phase, you will have a rough idea about the project as well as a fairly comprehensive list of system use cases, and you will know which users will be involved with each system use case. You won't know the details of each system use case yet, but you will know enough to be able to ballpark the project—for example, to say whether it will take days, weeks, or months.

The main deliverable of this phase is an early draft of a business requirements document (PRD). We take a "living document" approach to the PRD. You'll create it in this phase, and revise it as the project progresses. To help manage scope, you'll save a copy of the document at the end of each phase. This is what I mean by "set baseline" in the following list. Baselining allows you to see what the requirements looked like at various checkpoints in order to see, for example, whether a feature requested later by a stakeholder was within the scope as defined at that time.

Following is a list of the steps you'll carry out during this phase. 1a) Model business use cases i) Identify business use cases (business use-case diagram) ii) Scope business use cases (activity diagram)

1b) Model system use cases i) Identify actors (role map) ii) Identify system use-case packages (system use-case diagram) iii) Identify system use cases (system use-case diagram)

1c) Begin structural model (class diagrams for key business classes)

1d) Set baseline (PRD/Initiation)

Slide #6

The main objective of the Discovery phase is to understand the solution's desired behavior and baseline the architecture. This and the previous phase are the key phases for the PM. Requirements analysis peaks during this phase. (In iterative processes, analysis continues throughout the lifecycle; in waterfall processes, it is completed in this phase.) Some system use cases are selected for development during this phase in order to demonstrate architectural proofs of concept.

PM responsibilities during this phase focus on eliciting detailed requirements from stakeholders, analyzing and documenting them for verification by stakeholders and for use by solution providers. You will exploit a number of UML and complementary techniques to assist in requirements elicitation, analysis, and documentation during this phase.

Testing, in our context, is not just the running of programs to uncover errors; it includes other validation and verification activities as well as test planning and preparation. Following accepted quality assurance practices, I introduce testing long before the code is written. Hence, you'll find some testing activities also included in this phase. You'll learn to specify the degree of technical testing (white-box and system testing) required from the developers as well as how to design effective requirements-based test cases (black-box tests). By doing this during the Discovery phase, not only do you allow for enough lead time to set up these tests, but you also declare measurable criteria for the project's success: If the tests you've described don't "work as advertised," the product will not be accepted.

Please note than on an iterative project this phase may include a number of cycles, or iterations, in which case the above steps are repeated for each iteration (cycle) within the phase.

Slide #11

The OO principle of encapsulation suggests that in understanding how each object is used in a system, it's more important to know its operations than its attributes; operations are all that objects see of each other.

However, within the context of business analysis, it's usually easy to identify the attributes of a class: The attributes show up as fields on screens and reports, and it's often fairly obvious what class of objects they describe. Ascribing operations to classes is not quite as easy—and I like to do the easy things first. (However, when I'm doing OOD, I start with the operations.) Feel free to make changes to the order described for analyzing operations, attributes, or any other step. Consider B.O.O.M. your starting point. By following it, you will get to the end result—comprehensive requirements—relatively effortlessly. But you should, over time, customize the process as you see fit.

Slide #13

The B.O.O.M. steps are meant to be used as a checklist of items for the PM to consider when planning PM activities for a project—but not every step is required on every project. As a PM, your guiding principle in this regard should be, "If it isn't going to make a difference to the outcome, don't do it." Yet I see a lot of confusion amongst PMs about how much analysis to do on a given project. Are structural models (class diagrams and ERDs) always worth doing, or are they a waste of time? How much detail should you put into the user requirements? Obviously, blindly creating documentation without understanding its value—or if it even has any value—is not useful. The problem is when to do what. Following are some general guidelines.

The degree of documentation and analysis required for a project and the order in which analysis activities are carried out depends on a number of factors:

• The degree of formality versus adaptiveness of the lifecycle: The degree of a lifecycle's formality versus its adaptiveness (capacity to adjust to environmental conditions) is indicated by whether it is classified as a definitive or an empirical lifecycle. At one end of the continuum are definitive lifecycles, which follow a formal, well-defined process. Projects using this style of lifecycle will produce much of the documentation that we have discussed and to a comparable level of detail. At the other end of the continuum are empirical processes—less formal, adaptive processes, such as those that use an agile approach. Empirical processes require less analysis and documentation than definitive ones. Detailed user requirements are not documented on such projects because the requirements are in a constant state of flux and because the process relies on a heavily collaborative process of trial and error in order to determine what stakeholders want. On these projects, you might analyze the impact of the proposed change on business use cases and on their internal workflow, and identify and briefly describe system use cases and their main alternate flows (optional and error pathways), but not create detailed system use- case descriptions. Brief descriptions of system use cases are sufficient for project estimation and for planning iterations, but anything more than that is generally not necessary with this approach. Structural analysis still has a place in empirical lifecycles, especially when it relates to the business architecture, because of its value in defining business concepts and in discovering across-the-board business rules that are easy to miss. However, you are unlikely to produce a complete structural model on such projects. For empirical lifecycles, these are the rules to follow: -Do as little documentation as you can get away with. -Do it as late in the process as possible. -Don't baseline the requirements unless they are in the process of being implemented.
• Whether an iterative approach is being used: How analysis activities are sequenced within the development process is determined by whether the project is using a waterfall or an iterative lifecycle. With a waterfall lifecycle, all the analysis must be done up front before implementation begins. Hence, all the B.O.O.M. analysis steps must be completed by the end of the Discovery phase, before the Construction phase. On an iterative project (also referred to as iterative-incremental), the solution is developed in cycles, called iterations. Each iteration is like a mini-project, involving some degree of analysis, design, and coding, and should result in an increment of functionality; in other words, the user must be able to do something he or she could not do before. On such projects, the analysis is not all performed up front but continues through the Construction phase. For example, you might identify and briefly describe system use cases during the Initiation phase (as shown in the B.O.O.M. steps), fully describe those system use cases that exercise key architectural features during the Discovery phase, and complete the description of each system use case during the Construction iteration in which it will be implemented.
• The degree of uncertainty tolerated by the sponsor and the size of the budget: The type of lifecycle that is most appropriate for a project—and hence the timing and amount of analysis and documentation it entails—depends on many factors. One is the degree of uncertainty that the project sponsor and stakeholders are willing to accept. If the budget is large, clients are less likely to be willing to sign off on high-level documentation that leaves many of the details unknown. They often want to know exactly what they are paying for up front, before any development or procurement begins. In this case, the situation may dictate that a definitive, waterfall process be used. On the other hand, where a small budget is involved, clients may be willing to live with more uncertainty and, hence, be comfortable with an empirical approach.
• Regulatory requirements: Regulatory requirements have an impact on how much of the requirements must be pinned down in writing. If they require an extensive paper trail, the use of a definitive lifecycle is indicated.
• The size of the team and the physical distance between analyst, the solution team, and business stakeholders: Close proximity of solution providers and business stakeholders and small team sizes both argue for an empirical approach. Verbal communication works fine in these settings; indeed, formal, written documentation only slows down the process. On the other hand, when large teams or distances are involved, a definitive, well-defined process with formal documentation may be needed to facilitate coordination and communication.
• The capabilities of developers: The greater the expertise of the developers, the less documentation may be required. For example, if the team has deep experience handling software internationalization, then the requirements related to this issue need not be spelled out in detail.
• The type of solution being contemplated (in-house or vendor solution): In-house and custom solutions favor more documentation; vendor-supplied off-the-shelf solutions favor less documentation. Some of the business rules and requirements for the project are likely to be standard across the industry and are, therefore, likely to be supported in an off-the-shelf solution. These requirements entail less risk— and hence, less need for documentation—than those that are peculiar to the client organization.
• The maturity of the organization: In mature organizations, many processes and systems may already be documented, so the extent of new analysis and documentation required on a new project is less than on a less mature organization, where existing documentation is sparse.

Slide #14

Not every document you produce is aimed at the same audience. You need to tailor what you show to the audience that will see it. All the artifacts that we will be covering are appropriate for developers and other analysts on your team, but not all are appropriate for business stakeholders—at least not without some translation. The following is a summary of the artifacts that we will be covering and how they are presented to business stakeholders. You may want to re-read this section once you've learned more about these artifacts.

• Activity (workflow) diagrams: Show these to stakeholders, but only use the basic modeling elements. (Examples of other elements and inappropriate for stakeholders include signals and expansion regions.) Activity diagrams with partitions (swimlanes) help business stakeholders visualize the internal workflow of a business use case (business process); simple activity diagrams attached to system use cases help them visualize user-IT interactions when the flows through a system use case connect in complex ways.
• State-machine diagrams: Show business stakeholders simple diagrams only, indicating states and transitions but excluding advanced features (such as internal actions within a state and send events).
• Use-case diagrams: Show these to stakeholders, but only include actors and their relationships to use cases. Business use-case diagrams provide stakeholders with an overview of who participates in which processes; system use-case diagrams provide a useful overview of who does what with the IT solution. However, hide other modeling elements such as include, extend, and generalization relationships; these are useful internally for the team in reducing redundancies but they are apt to confuse stakeholders. (An exception may be made with respect to the include relationship if stakeholders are comfortable with it.)
• Use-case descriptions, decision tables, and decision trees: Show these to stakeholders.
• Class diagrams: Do not show these to stakeholders. Note, however, that they do contain important business rules; convert these to text and obtain sign-off on them.