1 / 50

Artifacts

Artifacts. Artifacts are either final or intermediate work products that are produced and used during a project. Artifacts are used to capture and convey project information. An artifact can be any of the following: A document , such as Business Case or Software Architecture Document

scoyne
Télécharger la présentation

Artifacts

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. Artifacts • Artifacts are either final or intermediate work products that are produced and used during a project. • Artifacts are used to capture and convey project information. Unit III

  2. An artifact can be any of the following: • A document, such as Business Case or Software Architecture Document • A model, such as the Use-Case Model or the Design Model • A model element; that is, an element within a model, such as a class, or a subsystem Unit III

  3. Example Unit III

  4. ARTIFACTS OF THE PROCESS • The artifacts of the process are organized into five sets: management, requirements, design, implementation, and deployment. • The management artifacts capture the information necessary to synchronize stakeholder expectations. • The requirements, design, implementation, and deployment artifacts are captured in rigorous notations that support automated analysis Unit III

  5. Most modern systems are composed of numerous components intended to execute in a heterogeneous network of distributed platforms. • They require a very different sequence of artifact evolution and a very different approach to trace ability. • Rather than being built sequentially, the artifacts are evolved together. • The primary difference from the conventional approach is that within each life-cycle phase, the workflow activities do not progress in a simple linear way, nor does artifact building proceed monotonically (sequence) from one artifact to another. Unit III

  6. ARTIFACT SETS Life cycle software artifacts are organized into Five distinct sets • Management (ad hoc textual formats) • Requirements (organized text and models of the problem space) • Design (models of the solution space) • Implementation (human-readable programming language and associated source files) • Deployment (machine-process able languages and associated files) Unit III

  7. Design Set Implementation set Deployment Set Requirement Set • Vision statement • Requirements model(s) • Design model(s) • Test model • Software architecture description • Source code baselines • Associated compile-time files • Component executables • Integrated product executable baselines • Associated run-time files • User manual Management Set Planning Artifacts Operational Artifacts • Release descriptions • Status assessments • Software change order database • Deployment documents • Environment • Work breakdown structure • Business Case • Release specifications • Software development plan Unit III

  8. Management Set • The management captures the artifacts associated with process planning and execution. These artifacts use ad hoc notations to capture the “contracts” among project personnel, among stakeholders, and between project personnel and stakeholders. • Specific artifacts included in this set are the WBS, the business case, the software development plan, the release descriptions, the status assessments, the software change orders, the deployment documents, and the environment. Unit III

  9. Management Artifact SetThe Project Management Artifact Set captures the artifacts associated with project and process planning and execution. Unit III

  10. Engineering Sets • Requirements set + design set + implementation set + deployment set • Each of these components of the system description evolves over time. Unit III

  11. Requirements Set • Structured text is used for the vision statement, which documents the project scope that supports the contract between the funding authority and the project team. • Ad hoc formats may also be used for supplementary specifications (such as regulatory requirements) and user mockups or other prototypes that capture requirements. • UML notation is used for engineering representations of requirements models (use case models, domain models). • The requirements set is the primary engineering context for evaluating the other three engineering artifact sets and is the basis for test cases. Unit III

  12. The Requirements Artifact set captures and presents information used in defining the required capabilities of the system. Unit III

  13. Design Set • UML notation is used to engineer the design models for the solution. The design set contains varying levels of abstraction that represent the components of the solution space (their identities, attributes, static relationships, dynamic interactions). • Design model include structural and behavioral information • Design model information can be straightforwardly and, in many cases, automatically translated into a subset of the implementation and deployment set artifacts. • Specific design set artifacts include the design model, the test model, and the software architecture description Unit III

  14. The Analysis & Design artifact set captures and presents information related to the solution to the problems posed in the Requirements set. Unit III

  15. Implementation Set • The implementation set includes source code that represents the tangible implementations of components and any executables necessary for stand-alone testing of components. • Implementation set artifacts can also be translated (compiled and linked) into a subset of the deployment set. • Specific artifacts include self-documenting product source code baselines and associated files (compilation scripts, configuration management infrastructure, data files), self-documenting text source code baselines and associated files, stand-alone component executables, and component test driver executables. Unit III

  16. Implementation Artifact SetThe Implementation Artifact Set captures and presents the realization of the solution presented in the Analysis & Design Set. Unit III

  17. Deployment Set • The deployment set includes user deliverables and machine language notations, executable software, and the build scripts, installation scripts, and executable target specific data necessary to use the product in its target environment. • Deployment set information can be installed,executed against scenarios of use, and dynamically reconfigured to support the features required in the end product. • Specific artifacts include executable baselines and associated run-time files, and the user manual. Unit III

  18. Deployment Artifact SetThe Deployment Artifact set captures and presents information related to transitioning the system presented in the Implementation set into the production environment Unit III

  19. Inception Elaboration Construction Transition Mgt. Req. Design. Impl. Deployment Life-Cycle focus on artifact sets Unit III

  20. Life-Cycle focus on artifact sets • Each artifact sets uses different notations to capture relevant artifacts • Management set notations capture the plans, process, objectives, and acceptance criteria. • Requirement notations capture the engineering context and the operational concept. Unit III

  21. Design notations capture the engineering blueprints (architectural design, component design). Implementation notations capture the building blocks of the solution in human-readable formats. Deployment notations (executables and data files) capture the solution in machine-readable formats. Unit III

  22. Software development toolsfor five artifact sets • Management: scheduling, workflow, defect tracking, change management, documentation, spreadsheet, resource management, and presentation tools. • Requirements: requirements management tools. • Design: visual modeling tools Unit III

  23. Implementation: compiler/debugger tools, code analysis tools, test coverage analysis tools, and test management tools. • Deployment: test coverage and test automation tools, network management tools, commercial components, and installation tools. Unit III

  24. ARTIFACTS EVOLUTION OVER THE LIFE CYCLE • The inception phase focuses mainly on critical requirements, usually with a secondary focus on an initial deployment view, little focus on implementation except perhaps choice of language and commercial components, and possibly some high-level focus on the design architecture but not on design detail. Unit III

  25. ARTIFACTS EVOLUTION OVER THE LIFE CYCLE • Elaboration phase there is much greater depth in requirements. This phase activities include the generation of an executable prototype. Unit III

  26. The main focus of construction is design and implementation. first it focus on the design artifacts, next emphasizing the design in source code and individually tested components. This phase should drive the requirements, design, implementation sets almost to completion. • The main focus of transition phase is achieving consistency and completion of the deployment set in the context of other sets. Residual defects are resolved and feed back from alpha, beta and system testing is incorporated. Unit III

  27. Unit III

  28. Software Process Framework • The Software Process Framework (SPF) is a document that provides information contained in the SEI Capability Maturity Model (CMM) for Software v1.1 (Paulk93a) in a format suitable for process definition and improvement. The SPF allows users to determine if their organization's software process documentation is consistent with the recommendations made by the CMM. Unit III

  29. When organizational software process documentation is found to be inconsistent with the CMM, the SPF provides the ability to make informed decisions regarding the applicability of specific CMM recommendations. Unit III

  30. Management artifacts • The management set includes several artifacts that capture intermediate results necessary to document the product /process legacy, maintain the product, improve the product , improve the process. Unit III

  31. Business case Unit III

  32. Business case(cont) • It provides all the information necessary to determine whether the project is worth investing in. • It details the expected revenue, expected cost, technical and management plans, and backup data necessary to demonstrate the risks and realism of the plans. • The main purpose is to transform the vision into economic terms so that an organization make accurate ROI assessment. Unit III

  33. Software development plan • The Software Development Plan is a comprehensive, composite artifact that gathers all information required to manage the project. It encloses a number of artifacts developed during the Inception phase and is maintained throughout the project Unit III

  34. Unit III

  35. Work breakdown structure (WBS): • It is the vehicle for budgeting and collecting costs. • A functional breakdown in the WBS will result in a functional decomposition in the software Unit III

  36. Software Change order Databases • Managing change is one of the fundamental primitives of an iterative development process. • With greater change freedom, a project can iterate more productively. • This flexibility increases the content, quality, and number of iterations that a project can achieve with in a given schedule. • All the software changes are tracked and managed using software change order database Unit III

  37. Release Specifications There are two important forms of requirements: vision statement:which captures the contract between the development group and the buyer. It captures the system requirements. It should understandable to the buyer. It uses use case model. eg: ad hoc format that may include text, mockups, use cases, spread sheets, or other formats. Evaluation criteria: Transient snapshots of objectives for a given intermediate lifecycle milestone. It is defined as management artifact rather than as part of requirement set It is represented by use cases, use case realizations, annotations on use cases, or structured text representations. Unit III

  38. Unit III

  39. Release descriptions • Release descriptions document describes the results of each release. • Release baselines should accompanied a release description document. • This document may also include metric summary that quantifies its quality in a absolute and relative terms. Unit III

  40. The results of post mortem review of any release would be documented here, including outstanding issues , recommendation for process and productive improvements, tradeoffs in addressing evaluation criteria, following up actions and similar information. Example: banking application Unit III

  41. Status assessments • Status assessments provide periodic snapshots of project health and status, including software project manager assessment, quality indicators, and management indicators. • The periodic status assessment document provide the critical mechanism for managing everyone’s expectations throughout the lifecycle. • Typical status assessment should include a review of resources, personnel staffing, financial data, top 10 risks, technical progress, major milestone plans and results, total project or product scope. Unit III

  42. Environment • A robust, integrated development and maintenance environment must support automation of the development process. • It should include requirements management, visual modeling, document automation, host and programming tools, automated regression testing, and continuous and integrated change management. Unit III

  43. Deployment • Deployment document can take many forms. • It may include computer system operations manuals, s/w installation manuals, plans and procedures, site surveys etc.. • For commercial software products it may include Transition plans, marketing plans, sales plans, and training course plans Unit III

  44. Management Artifact sequence Unit III

  45. Engineering Artifacts Engineering Artifacts are captured in rigorous engineering notations such as UML, programming languages, or executable machine codes. Three Engineering Artifacts are: 1. Vision Document. 2. Architecture Description. 3. S/W User Manual. Unit III

  46. Vision Document • The source for capturing the expectations among stakeholders. • Written from the users’ perspective. • Focus is on essential features of the system, and the acceptable levels of quality. • Includes the operational concept. Unit III

  47. Architecture Description • It provides an organized view of the software architecture under development. • It includes views of the design, implementation and deployment sets to achieve the operational concept of requirement set. • It can be described using a subset of the design model or as an abstraction of the design model or combination of both. Unit III

  48. Unit III

  49. S/W User manual • It provides the user with the reference documentation necessary to support the delivered software. • It should include installation procedures, usage procedures and guidance, operation constraints and user interface description. • It should be written by members of the test team Unit III

  50. Pragmatic Artifacts • People want to review information but don’t understand the language of the artifact. • People want to review the information but don’t have access to the tools. • Human readable engineering artifacts should use rigorous notations that are complete, consistent and used in a self documenting manner. • Useful documentation is self defining: It is documentation that gets used. • Paper is tangible: electronic artifacts are too easy to change. Unit III

More Related