Concurrent Activities Specification and Validation Process
The project involves initiating, discovering, constructing, and verifying concurrent activities through a series of phases like business case development, solution exploration, software testing, and final deployment management. Key tasks include prototyping, requirement analysis, design, coding, and testing at each stage of the software development life cycle. The initiation phase focuses on developing the business case, defining project scope, and identifying key functionalities, while the final phase involves testing, deployment, and project closure.
Download Presentation
Please find below an Image/Link to download the presentation.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author.If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.
You are allowed to download the files provided on this website for personal or commercial use, subject to the condition that they are used lawfully. All files are the property of their respective owners.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author.
E N D
Presentation Transcript
Concurrent activities Initial version Specification Outline description Intermediate versions Development Final version Validation
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 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.) leading to an
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.
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 BA 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 BA. 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. In this book, 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 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 meaningful interactions with the IT system. to help you and business processes into
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 (BRD/Initiation)
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 theBA. 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. BA responsibilities during this phase focus on eliciting detailed requirements from documenting them for verification by stakeholders and for use by solution providers. You will exploit a number of UML and complementary requirements elicitation, analysis, during this phase. stakeholders, lyzing and techniques to documentation assist in and
System use-case descriptions (specifications), storyboarding the interaction between users and the proposed IT system as each system use case is played out State-machine diagrams describing the lifecycle of key business objects Class diagrams describing key business concepts and business rules that apply to business objects such as accounts, investments, complaints, claims, and so on
Behavioral analysis i) Describe system use cases (use-case description template) ii) Describe state behavior (state-machine diagram) 1. Identify states of critical objects 2. Identify state transitions 3. Identify state activities 4. Identify superstates 5. Identify concurrent states
Structural analysis (object/data model) (class diagram) i) Identify entity classes ii) Model generalizations iii) Model transient roles iv) Model whole-part relationships v) Analyze associations vi) Analyze multiplicity vii) Link system use cases to the structural model viii) Add attributes ix) Add lookup tables x) Distribute operations xi) Revise class structure
Specify testing (test plan/decision tables) i) Specify white-box testing quality level ii) Specify black-box test cases iii) Specify system tests Specify implementation plan (implementation plan) Set baseline for development (BRD/Discovery)
Business-analysis depends on the lifecycle approach being used. On waterfall projects, where all the analysis is done up front, there is no requirements gathering or analysis during this phase; however, the BA is involved in supporting quality assurance and validating that the technical design meets the requirements (for example, by reviewing test plans and design specifications). On iterative projects, where requirements development take place iterations, the steps described for the Discovery phase (steps 2a through 2e) are carried out during each iteration of the Construction phase. activity during this phase analysis over and a solution number of
The business analyst supports final testing before the completed solution is deployed, reviewing test plans and results and ensuring that all requirements are tested.
The business analyst supports the deployment process, reviewing participating in a post-implementation review (PIR) to evaluate the success of the change. transition plans and
The Business Analysis Body of Knowledge Version 2.0 (BABOK businessanalysis through a set of areas of expertise, referred to as knowledge areas (KAs). Knowledge areas define what a practitioner of business analysis needs to understand and the tasks a practitioner must be able to perform. 2) describes
Knowledge Area (KA) Business Analysis Planning and Monitoring Definition Task KA covers how business analysts determine which activities are necessary in order to complete a business analysis effort. It covers identification of stakeholders, selection of business analysis techniques, the process that will be used to manage requirements, and how to assess the progress of the work. 2.1 Plan Business Analysis Approach 2.2 Conduct stakeholders Analysis 2.3 Plan Business Analysis Activities 2.4 Plan Business Analysis Communication
Knowledge Area (KA) Elicitation Definition Task KA describes how business analysts work with stakeholders to identify and understand their needs and concerns, and understand the environment in which they work. The purpose of elicitation is to ensure that a stakeholder s actual underlying needs are understood, rather than their stated or superficial desires. 3.2 Conduct Elicitation Activity
Knowledge Area (KA) Requirements Management and Communication Definition Task KA describes how business analysts manage conflicts, issues, and changes in order to ensure that stakeholders and the project team remain in agreement on the solution scope, how requirements are communicated to stakeholders, and how knowledge gained by the business analyst is maintained for future use. 4.3 Maintain Requirements for Reuse 4.4 Prepare Requirements Package 4.5 Communicate Requirements
Knowledge Area (KA) Enterprise Analysis Definition Task KA describes how business analysts identify a business need, refine and clarify the definition of that need, and define a solution scope that can feasibly be implemented by the business. This knowledge area describes problem definition and analysis, business case development, feasibility studies, and the definition of solution scope. 5.2 Assess Capability Gaps 5.4 Define Solution Scope
Knowledge Area (KA) Requirements Analysis Definition Task KA describes how business analysts prioritize and progressively elaborate stakeholder and solution requirements.... It involves analyzing stakeholder needs to define solutions that meet those needs, assessing the current state of the business to identify and recommend improvements, and the verification and validation of the resulting requirements. 6.2 Organize Requirements 6.3 Specify and Model Requirements 6.5 Verify Requirements 6.6. Validate Requirements
Knowledge Area (KA) Solution Assessment and Validation Definition Task KA describes how business analysts assess proposed solutions to determine which solution best fits the business need, identify gaps and shortcomings in solutions, and determine necessary workarounds or changes to the solution. It also describes how business analysts assess deployed solutions to see how well they meet the original need so that the sponsoring organization can assess the performance and effectiveness of the solution. 7.2 Allocate Requirements 7.3 Assess Organizational Readiness 7.5 Validate Solution
This subsection covers the purpose, activities, work products, and milestone of the Inception phase. The purpose of the Inception phase is to ensure that the project is both valuable and feasible (scope and business value). For any truly new piece of software, or even for the novel adaptation of an existing system, at some moment in the mind of the developer, the architect, the analyst, or the end user, an idea for some application springs forth. This idea may represent a new business venture, a new complementary product in an existing product line, or perhaps a new set of features for an existing software system. It is not the purpose of the Inception phase to ompletely define this idea. Rather, this phase s purpose is to establish the vision for the idea and validate its assumptions. Even for the refinement of an existing system, there is still value in the Inception phase. In such cases, Inception is brief but still focuses on ensuring business value and technical feasibility.
This subsection covers the purpose, activities, work products, and milestone of the Elaboration phase. Purpose Once the scope of what is to be built is understood and agreed developing the overall architecture framework that will provide the foundation for all the iterations that follow. The intent is to identify architectural flaws early and to establish common policies that yield a simpler architecture. The Elaboration phase is when such architectural discovery takes place, choices are made, and the architecture evolves across multiple iterations. This evolution is driven by the mitigation of the highest risks and the implementation of the requirements with the highest priority and the most architectural significance. to, attention turns to
This subsection covers the purpose, activities, work products, and milestone of the Construction phase. Purpose Once the architecture has stabilized, the focus shifts from understanding the problem and identifying key elements of the solution to the development of a deployable Construction phase is when you move from discovery into production, where production can be thought of as a controlled methodological process of raising product quality to the point where the product can be shipped product. The
This subsection covers the purpose, activities, work products, and milestone of the Transition phase. Purpose : The Transition phase is when you ensure that the software is acceptable to its end users. Activities During the Transition phase, the product is provided to the user community for evaluation and testing (e.g., alpha testing, beta testing, and so on). The development team then incorporates the feedback received. The focus of Transition is on fine-tuning the product; addressing configuration, installation, addressing issues raised by the documentation also undergoes final development, as does any applicable training material. Any production-related issues, such as packaging and marketing materials, are also handled. The resulting product then undergoes acceptance testing. It is important to note that even though testing has been performed throughout the lifecycle, end-user testing and final acceptance testing is still important as such testing ensures that the developed product fulfills its acceptance criteria at both the development and target installation sites. and early usability adopters. issues; Supporting and
