(圖片出處：博客來網路書店)
----------
Ch2:Key Principles for Business-Driven Development
Thoroughly Document Precise Requirements and Force Stakeholder Acceptance
Identifying true software requirements is a continuing process of learning and defining.
Nurture Heroic Developers Willing to Work Extremely Long Hours, Including Weekends
If the project is planned, resources, and executed appropriately, there should be no need for anyone to work long hours and weekends.
Enabling Feedback
Requirements are commonly misunderstood or incomplete and frequently change. Based on this knowledge, how could a project team deliver a system for which the requirements set cannot be stable?
Therefore, the longer the period between the initial input of requirements and the feedback at the end, the higher the likelihood that requirements might change.
To effectively demonstrate value iteratively, you need to establish a path of enabling and encouraging feedback.
Plan the Entire Project in Detail
When you don't break down the entire project into smaller chunks, the planning process can become time-consuming and less reliable.
Rely on Deliverables Other Than Test Results or Demonstrations
The most important outcome of the software engineering process is most likely working software.
Elevate the Level of Abstraction
With this key principle in mind, the project team will major benefits: improved productivity and reduced complexity.
----------
Ch5:Business Modeling
In short, business modeling enables a deeper and clearer understanding of the business operations, which constitutes one of the most important inputs into a system's development.
Business Use-Case Model
Besides communication with stakeholders, the project manager uses this model for iteration planning.
Domain Modeling
A domain model is also referred to as an "incomplete" business analysis model.
----------
Ch6:Requirements
Overview
Incomplete requirements and lack of user involvement are the two top reasons cited for project failure.
Analyze Problem
One of the other key artifacts required to be produced early in the project is the Requirements Management Plan. This plan provides guidance on the requirements artifacts that should be developed, different requirements types that should be manages for the project, the relevant requirement attributes that should be collected, and the approach to requirements traceability that will be used in managing the product requirements. The System Analyst develops the Requirements Management Plan.
Understand Stakeholder Needs
According to the RUP, a requirement is defined as "a condition or capability to which a system must conform."
You can use Storyboards to explore, understand, and analyze the behavioral requirements of the system, especially how the users will interact with the system.
Here, you will realize that certain requirements do not fit appropriately within the use cases. Such requirements are documented in the Supplementary Specifications.
Define the System
Specifically, in the Use-Case Model, use cases are now outlined.
As a result of a deeper understanding of the use cases, non-use-case-specific requirements are further documented or refined in the Supplementary Specification.
Manage the Scope of the System
An important concept that contributes toward keeping the body of requirements work manageable is prioritization.
The Software Architecture prioritizes the use cases.
Factors that make use cases architecturally significant include the benefits to the stakeholder, the architectural impact, the risks to be mitigated, the completion of the architectural coverage, and other key objectives and imposed constraints. Prioritize poorly understood and architecturally significant use cases for clarification and stabilization.
Supplementary Specifications
Many types of requirements do not fall within the scope of functional requirements. Therefore, these are not readily captured in the use cases. Supplementary Specifications capture such nonbehavioral system requirements.
Use-Case Model
It is used as an essential input to activities in Analysis and Design, Implementation, and Test.
Use Cases and the Other RUP Disciplines
Use cases play an important role in most RUP disciplines. They are at the heart of requirements; realization of these use cases is carried out with analysis and design, and the wywtem is implemented and tests are planned and executed based on the use cases. Use cases actually drive the development process from understanding the requirements to implementing the system the meets those requirements.
Testing
Use cases become the foundation for identifying the test cases and test procedures. In other words, the system is verified by performing each use case.
Deployment
Use cases play the central role in developing user's manuals and in defining how to order units of the product.
Use-Case Model
The Use-Case Model, which determines what the system should do from the user's point of view, is one of the key artifacts produced by the Requirements discipline. A Use-Case Model drives the planning, design, development, and testing of the product.
Use Case
While identifying the use cases, keep in mind that an actor should not be expected to perform several use cases to realize the value to be provided by the system. A use case specifies a dialogue between an actor and the system that must yield value. An actor initiates a use case, which invokes certain functionality in the system. The use cases must enable the system to deliver all the expected functionality.
Requirements Traceability
One potential impact of this is the fact that change in a given use case needs to be carefully traced down to the actual functionality delivered by the system. Lack of traceability can result in a system that doesn't deliver the right functionality.
As expected, another major advantage of traceability in in managing change -- the ability to determine the impact of the change in terms of things that need to be updated as a result of change.
Requirements and Other Disciplines
The Test discipline validates that system against (among other things) the requirements.
----------
Ch7:Analysis and Design
In the Rational Unified Process, analysis and design are combined into one discipline even though they are two separate techniques.
The boundaries are often not precisely drawn, and it is not uncommon for one person to fill the roles of both System Analyst and Designer. In RUP, however, the System Analyst role plays a more central role in the Requirements discipline than the Designer does. The Software Architect performs most of the analysis tasks, whereas the Designer is responsible for the design aspects.
Overview
The evaluation, validation, and design of architecture falls also into the scope of the Analysis and Design discipline, which emphasizes the role of this discipline and that RUP is an architecture-centric process framework.
Model-Driven Development and Model-Driven Architecture emphasize the role of models as the foundational elements for implementation.
Analysis models evolve into design models and design models evolve throughout the life of the project. There are no hard and fast riles on when you can start producing implementation elements and integrate them into interesting builds of the system.
One of the initial tasks to successfully perform architectural synthesis is analyzing the architecture. Accordingly, the Software Architect performs architectural analysis, defines a candidate architecture, and constrains the architectural techniques to be used in the system. Performing architectural analysis and constructing and assessing the viability of the architectural proof-of-concept.
Defining the hight-level organization of subsystems and introducing the contents of the layered architecture.
Activity: Analyze Behavior
Identifying subsystem interfaces to ensure smoth collaboration between subsystems.
Analysis Model
The Analysis Model is a generalization or abstraction of the design and does not provide details on how the system will deliver the needed functionality.
Design Model
Visual models allow the design to be easily communicated. Tools are available that can ensure consistency with the implementation model and improve efficiencies. In RUP, the Design Model is the primary artifact of the Analysis and Design discipline. It is an object model describing the realization of use cases. The Design Model serves as an abstraction of the implementation model and its source code and is used as essential input to activities in implementation and testing.
Data Model
This artifact describes the logical and physical representations of persistent data that the application uses. When the application will utilize a relational database management system(RDBMS), the data model can also include model elements for stored procedures, triggers, constraints, and so on that define the interaction of the application components with the RDBMS.
Reference Architecture
This artifact is, in essence, a predefined architectural pattern, or set of patterns, possibly partially or completely instantiated, designed and proven for use in particular business and technical contexts, together with supporting artifacts to enable their use.
Navigation Map
The purpose of the Navigation Map is to express the principal user interface paths thought the system. Note that these are the main pathways through the screens of the system and not necessarily all of the possible paths. Therefore, the Navigation Map describes the structure of the user interface elements in the system, along with their potential navigation pathways.
Service Model
The Service Model is an abstraction of the IT services implemented within an enterprise. It supports the development of one or more service-oriented solutions and is used to conceive and document the design of the software services. The Service Model, therefore, is defined as a model of the core elements of a service-oriented architecture (SOA).
System Analyst
This role leads and coordinates requirements elicitation by outlining the system's functionality and delimiting the system.
Use Cases and Analysis and Design
The Use-Case Model and Supplementary Specification comprise the two key inputs into the Analysis and Design discipline from the Requirements discipline. Analysis transforms the functional requirements, documented in the form of use cases, into a form that can be seamlessly mapped to a set of classes and subsystems. Although analysis does not account for nonfunctional requirements to maintain simplicity, the design activities evolve and detail the Analysis Model while keeping in view the constraints imposed by nonfunctional requirements, the implementation environment, performance and availability requirements, and others. Jointly, code and acts as a blueprint of how the source code is structured and written.
During the early iterations of the Elaboration phase, the design activities focus on the creation of an Architectural Proof-of-Concept, which serves as an important foundation for developing a high-quality design model.
Use Case Realization in Analysis and Design
Use cases define system behavior, and objects implement the behavior. At runtime, objects collaborate to perform expected functions of the system. A use-case realization describes how a particular use case is realized within the design model in terms of collaborating objects. Classes need to be implemented for objects to exist, and objects can only collaborate if the rights and specifies what classes need to be implemented to realize each use case. Therefore the complete behavior of use case is allocated to collaborating classes. The use-case realization enables designers of participating classes to clearly understand the role of a particular class in realizing a use case and its relationship to other classes. The information enable further refinement of class responsibilities and interfaces. In terms of UML models, sequence, class, and communication, diagrams are built to design use-case realization.
Components and Subsystems
The term component refers to a range of different things, but often specifically to denote characteristics that enable replacement and assembly in larger systems. In the RUP, a component is defined as an encapsulated part of a system, ideally nontrivial, nearly independent, and replaceable. It is a part of a system that fulfils a clear function in the context of a well-defined architecture. Components implement clearly defined functionality that is made available through one or more interfaces.
Subsystem is a design model element that corresponds to the component. It has the semantics of a package, such that it can contain other model elements. The behavior of the subsystem is provided by classes or other subsystems it contains. A subsystem realizes one or more interfaces, which define the behavior it can perform.
Use-Case Realization
A use-case realization represents how a use case will be implemented in terms of collaborating objects. Separating the use-case realization from its use case allows the use cases to be managed separately from their realizations. In other words, it enables us to separate requirements-related concerns from design-related ones. This is particularly important for larger projects or families of systems where the same use cases might be designed differently in different products within the product family. For each use case in the use-case model, there is a use-case realization in the analysis/design model with a realization relationship to the use case.
Summary
We have also discussed the role of the software architect, who plays a significant role in this discipline by deciding on the architectural approach—for example, service-oriented architecture (SOA) or component-based architecture.
----------
Ch8:Implementation
In the Rational Unified Process, the Implementation discipline is where actual code is produced, subsystems are integrated, and the system is implemented. Unit tests are performed while implementing the system. In iterative and incremental development, implementation is initiated early in the project.
Overview
Testing during implementation is limited to unit testing. Other tests, such as the system test and the integration test, are carried out within the Test discipline.
Structure the Implementation Model
The Software Architect is responsible for structuring the Implementation Model. He produces a set of Implementation Subsystems that he can develop relatively independently. A well-organized Implementation Model prevents configuration management problems and allows the product to build up from successively larger integration builds.
Plan the Integration
Planning the integration is focused on which implementation subsystem should be implemented and in which order to integrate the implementation subsystems in the current iteration. You should plan the integration process early, at least in rough form, when the architecture is baselined.
Implement Components
If he discovers defects in the design, he submits rework feedback on the design.
Implementation Model
The Implementation Model is a collection of components and the implementation subsystem that contain them. Note that the term model here is not meant to connote diagrams and other more abstract representations. Instead, an Implementation Model consists of Implementation Elements, Implementation Subsystems, and elements created to support developer testing.
Build
The purpose of a Build, constructed from other elements in the implementation, is to deliver a testable subset of the runtime functions and capabilities of the system.
A Build is an operational version of a system or a part of the system that demonstrates a subs of the capabilities provided in the final product. The Build constitutes an integral part of the iterative development lifecycle and provides review points. Note that in the RUP, like in all iterative incremental development processes, progress is demonstrated via an executable, a (working) software deliverable rather than just documents or the like. The lifecycle "provides review points," but the Build is reviewable and objectively demonstrates progress tow
completion. The Build is examined at the review points that the lifecycle provides.
----------
Ch9:Test
Overview
Therefore, the testing approach recommended by the Rational Unified Process focuses on maximizing the effectiveness of an organization’s testing efforts.
Purpose
To prove the validity of the assumptions made in the design and requirement specification through concrete demonstration.
To validate that software product functions as designed.
To validate that the requirements have been implemented appropriately.
----------
Ch10:
----------
Ch11:
(未完，閱讀中)
0 回應:
張貼意見