1 / 42

Development Process and Product Life Cycle

Development Process and Product Life Cycle. Process. Process and Roles. System Development Process Basic Activities. The Software Process in Reality. Requirements of Development Process Today. Waterfall. V Model. Development Process – shorter life cycle. Evolutionary development….

krise
Download Presentation

Development Process and Product Life Cycle

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Development Process and Product Life Cycle

  2. Process

  3. Process and Roles

  4. System Development ProcessBasic Activities

  5. The Software Process in Reality

  6. Requirements of Development Process Today

  7. Waterfall

  8. V Model

  9. Development Process – shorter life cycle

  10. Evolutionary development…

  11. Prototyping Model Used in combination with Waterfall Model

  12. The incremental and iterative models

  13. SDLCs (systems development lifecycle) • Initiation: Make the business case for the project. Work also begins on the userexperience and on drafts of architectural proof of concepts. The prototyping effortduring the Initiation phase should be risk-driven and limited to gaining confidencethat a solution is possible. • Discovery: Conduct investigation leading to an understanding of the solution’sdesired behavior. (On iterative projects, requirements analysis peaks during thisphase 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 withinthe phase. Design and coding appear in all phases, but peak during this phase.)

  14. SDLCs (systems development lifecycle) • Final Verification and Validation (V&V): Perform final testing before the productor 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.

  15. B.O.O.M (Business Object Oriented Modeling)Step 1: Initiation • The objectives of the Initiation phase are to develop the business case for the project, establishproject and product scope, and explore solutions, including the preliminary architecture.The BA assists the project manager by identifying stakeholders, business services andprocesses, and IT services affected by the project. By the end of this phase, key functionalityis identified, such as key system use cases (user tasks) and IT services. When a non-agileprocess is used, these requirements are baselined and subsequent changes to scope aremanaged 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 arough cut at the business case for a proposed IT project. The trouble is that without knowingthe 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 requirementanalysis. 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 onhigh-level needs. These techniques are as follows:

  16. Techniques • Business use cases: A tool for identifying and describing end-to-end businessprocesses affected by the project. • Activity diagrams: Used to help you and stakeholders form a consensus regardingthe 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 businessprocesses into meaningful interactions with the IT system.

  17. The Aims : • 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)

  18. Step 2: Discovery • The main objective of the Discovery phase is to understand the solution’s desired behaviorand baseline the architecture. This and the previous phase are the key phases for theBA. Requirements analysis peaks during this phase. (In iterative processes, analysis continuesthroughout the lifecycle; in waterfall processes, it is completed in this phase.) Somesystem 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 stakeholders,lyzing and documenting them for verification by stakeholders and for use bysolution providers. You will exploit a number of UML and complementary techniques toassist in requirements elicitation, analysis, and documentation during this phase.

  19. Techniques • System use-case descriptions (specifications), storyboarding the interactionbetween 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 tobusiness objects such as accounts, investments, complaints, claims, and so on

  20. 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

  21. 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

  22. 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)

  23. Step 3: Construction • Business-analysis activity during this phase depends on the lifecycle approach being used.On waterfall projects, where all the analysis is done up front, there is no requirements gatheringor analysis during this phase; however, the BA is involved in supporting quality assuranceand validating that the technical design meets the requirements (for example, byreviewing test plans and design specifications). On iterative projects, where requirementsanalysis and solution development take place over a number of iterations, the stepsdescribed for the Discovery phase (steps 2a through 2e) are carried out during each iteration of the Construction phase.

  24. Step 4: Final Verification and Validation (V&V) • The business analyst supports final testing before the completed solution is deployed,reviewing test plans and results and ensuring that all requirements are tested.

  25. Step 5: Closeout • The business analyst supports the deployment process, reviewing transition plans and participating in a post-implementation review (PIR) to evaluate the success of the change.

  26. Using Babok (Business Analysis Body of Knowledge) • The Business Analysis Body of Knowledge Version 2.0 (BABOK 2) describes businessanalysisthrough 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.”

  27. Unified Process (UP)

  28. Inception • 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 isboth valuable and feasible (scope and business value). For any truly new piece ofsoftware, or even for the novel adaptation of an existing system, at some momentin the mind of the developer, the architect, the analyst, or the end user, an idea forsome application springs forth. This idea may represent a new business venture, anew complementary product in an existing product line, or perhaps a new set offeatures for an existing software system. It is not the purpose of the Inceptionphase to ompletelydefine this idea. Rather, this phase’s purpose is to establishthe vision for the idea and validate its assumptions. Even for the refinement of anexisting system, there is still value in the Inception phase. In such cases, Inceptionis brief but still focuses on ensuring business value and technical feasibility.

  29. Elaboration • 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 to,attention turns to developing the overall architecture framework that will providethe foundation for all the iterations that follow. The intent is to identify architecturalflaws 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. Thisevolution is driven by the mitigation of the highest risks and the implementationof the requirements with the highest priority and the most architectural significance.

  30. Construction • This subsection covers the purpose, activities, work products, and milestone of the Construction phase. • Purpose Once the architecture has stabilized, the focus shifts from understandingthe problem and identifying key elements of the solution to the developmentof a deployable product. The Construction phase is when you move fromdiscovery into production, where production can be thought of as “a controlledmethodological process of raising product quality to the point where the product can be shipped”

  31. Transitions • 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 usercommunity for evaluation and testing (e.g., alpha testing, beta testing, and so on).The development team then incorporates the feedback received. The focus ofTransition is on fine-tuning the product; addressing configuration, installation,and usability issues; and addressing issues raised by the early adopters. Supportingdocumentation also undergoes final development, as does any applicabletraining material. Any production-related issues, such as packaging and marketingmaterials, are also handled. The resulting product then undergoes acceptancetesting. It is important to note that even though testing has been performedthroughout the lifecycle, end-user testing and final acceptance testing is stillimportant as such testing ensures that the developed product fulfills its acceptancecriteria at both the development and target installation sites.

More Related