1 gioi thieu httt

902 views
757 views

Published on

Published in: Education, Business
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
902
On SlideShare
0
From Embeds
0
Number of Embeds
5
Actions
Shares
0
Downloads
12
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • System Boundary – Phạm vi hệ thống Bao gồm các thành phần chịu ảnh hưởng mạnh mẽ bởi hệ thống sở hữu chúng. System Environment – Môi trường hệ thống "Các thành phần bên ngoài mà sự thay đổi hành vi, ứng xử hay thuộc tính của chúng ảnh huởng tới trạng thái của hệ thống và các thành phần này cũng bị ảnh hưởng bởi ứng xử của hệ thống." (Lucey) Subsystem - Hệ thống con Là một hệ thống bên trong hệ thống khác. Interface – Giao diện Nơi mà sự tương tác xảy ra giữa 2 hệ thống/ hệ thống con.
  • Môi trường tổ chức: Môi trường bên ngoài chứa các tổ chức khác liên quan đến hoạt động của tổ chức. Môi trường kinh tế: khách hàng, nhà cung cấp, ngân hàng, … Môi trường xã hội: nhà nước, công đoàn, …
  • Các đặc điểm của thông tin “tốt” relevance : thích hợp accuracy : chính xác completeness : đầy đủ confidence in the source : nguồn thông tin tin cậy communication to the right person : truyền đạt tới đúng người timing : cập nhật detail : chi tiết channels of communication : là kênh truyền thông understandability : dễ hiểu
  • Broad definition An IS is a means of processing which generates information may be informal, manual, computer-based
  • Các mức ra quyết định Mức chiến lược (Strategic level): Dài hạn, liên quan đến các vấn đề phức tạp, tính không chắc chắn và rủi ro cao. Ví dụ: Xác định các mục tiêu cho công ty, lập kế hoạch để đạt được các mục tiêu, chọn dòng sản phẩm mới, lĩnh vực kinh doanh mới, … Mức chiến thuật (Tactical level): giám sát tổ chức ở bất cứ thời điểm nào. Đảm bảo đạt được và sử dụng hiệu quả các tài nguyên Ví dụ: Quyết định ngân quỹ bộ phận, quy hoạch các vị trí nhân viên, chọn sản phẩm cải tiến, lập kế hoạch công việc trung hạn, … Mức thực hiện (Operational level) Đảm bảo các nhiệm vụ cụ thể được thực hiện hiệu quả Ví dụ: Tuyển nhân viên, lập lịch sản xuất, quản lý tồn kho, …
  • Give examples of each along the line of banking systems dealing with transfer of funds etc. Leisure industry systems in box office ticket sales etc. Worth pointing out that TPS have a wide variety of differing requirements but also there is a great deal of commonality e.g. all TPS have large volumes of similar transactions, detailed data needed. These themes will be covered in detail in week 2.
  • As above but emphasise the importance of control in RT systems. Give examples of generic commonality and specific differences in RT systems.
  • Again as above for MIS. Explain that different types of MIS exist with different purposes and also aimed at different levels within management.
  • In this module, you will learn about recommended software development Best Practices and the reasons for these recommendations. Then you will see how the Rational Unified Process (RUP) is designed to help you implement the Best Practices. The Best Practices are the key terms and concepts introduced in this module.
  • The stakeholder role is defined as anyone who is materially affected by the outcome of the project.  Effectively solving any complex problem involves satisfying the needs of a diverse group of stakeholders. Typically, stakeholders will have different perspectives on the problem and different needs that must be addressed by the solution. Many stakeholders are users of the system. Other stakeholders are only indirect users of the system or are affected only by the business outcomes that the system influences. Many are economic buyers or champions of the system. An understanding of who the stakeholders are and their particular needs are key elements in developing an effective solution. Examples of stakeholders: Customer or customer representative User or user representative Investor Shareholder Production manager Buyer Designer Tester Documentation writer and so on
  • By treating these root causes, you will eliminate the symptoms. By eliminating the symptoms, you ’ ll be in a much better position to develop high-quality software in a repeatable and predictable fashion. Best Practices are a set of commercially proven approaches to software development, which, when used in combination, strike at the root causes of software development problems. They are called “ Best Practices, ” not because we can precisely quantify their value, but because they have been observed to be commonly used in the industry by successful organizations. The Best Practices have been harvested from thousands of customers on thousands of projects and from industry experts. Animation note: The first mouse click highlights: Symptom The second mouse click highlights: Root Causes The third mouse click highlights: - Best Practices
  • This slide may be confusing unless it is explained properly. Use this opportunity to briefly discuss each of the Best Practices. They will be presented more thoroughly in subsequent slides. Ask the students if they can identify some Best Practices of their own. This slide is intended to illustrate how the Best Practices used together provide much more benefit than each individually. The slide only illustrates how one of the Best Practices (Develop Iteratively) supports the others. How others interact might make a good discussion point for the students. For example, how do Manage Change and Continuously Verify Quality relate? The answer is that there is no point in running a test against an unknown configuration and no point in writing a defect against an unknown baseline. Similarly, there is no point in controlling changes until you have reached a stable level of quality in a product. Remind the students that the Best Practices reinforce each other. In the case of our Best Practices, the whole is much greater than the sum of the parts. Each of the Best Practices reinforces and, in some cases, enables the others. This slide shows just one example: how iterative development supports the other five Best Practices. However, each of the other five practices also enhances iterative development. For example, iterative development done without adequate requirements management can easily fail to converge on a solution. Requirements can change at will, which can cause users not to agree and the iterations to go on forever. When requirements are managed, this is less likely to happen. Changes to requirements are visible, and the impact on the development process is assessed before the changes are accepted. Convergence on a stable set of requirements is ensured. Similarly, every Best Practices supports each of the other Best Practices. Hence, although it is possible to use one Best Practice without the others, this is not recommended, since the resulting benefits will be significantly decreased.
  • Developing iteratively is a technique that is used to deliver the functionality of a system in a successive series of releases of increasing completeness. Each release is developed in a specific, fixed time period called an “ iteration. ” Each iteration is focused on defining, analyzing, designing, building and testing some set of requirements. Keep the concept of iterative development at a very high level in this module. It is easy to get bogged down in the many ramifications of iterative development. Try just to get the concept across. The Essentials of the Rational Unified Process course covers this in more detail.
  • Waterfall is conceptually straightforward because it produces a single deliverable for each step (requirements, analysis model, design model, code, etc), resulting in a single release. The fundamental problem is that it pushes risk forward in time, where it ’ s costly to undo mistakes from earlier phases. An initial design will likely be flawed with respect to its key requirements, and furthermore, the late discovery of design defects tends to result in costly overruns or project cancellation. The waterfall approach tends to mask the real risks to a project until it is too late to do anything meaningful about them. To illustrate a problem with the waterfall model: Suppose I estimate that the project will take two years, and it really takes three years. At the end of two years, what do I have? Nothing useful works. No partial delivery is possible. Diagrams and models are great, but they can not execute.
  • Iterative processes were developed in response to these waterfall characteristics. With an iterative process, the waterfall steps are applied iteratively. Instead of developing the whole system in lock step, an increment (that is, a subset of system functionality) is selected and developed, then another increment, and so on. The selection of the first increment to be developed is based on risk, the highest priority risks first. To address the selected risk(s), choose a subset of use cases. Develop the minimal set of use cases that will allow objective verification , for example, through a set of executable tests, of the risks that you have chosen. Then select the next increment to address the next highest risk, and so on. Thus you apply the waterfall within each iteration, and the system evolves incrementally. P: Planning R: Requirements analysis D: Design C: Code and unit test I: Integration T:Test In the iterative approach, the waterfall is applied to a single system increment at a time. Each iteration produces an executable.
  • Developing iteratively is a technique that is used to deliver the functionality of a system in a successive series of releases of increasing completeness. Each release is developed in a specific, fixed time period called an iteration . Each iteration is focused on defining, analyzing, designing, building, and testing a set of requirements. The earliest iterations address the greatest risks. Each iteration includes integration and testing and produces an executable release. Iterations help: Resolve major risks before making large investments. Enable early user feedback. Make testing and integration continuous. Define a project ’ s short-term objective milestone. Make deployment of partial implementations possible. Instead of developing the whole system in lock step, an increment (for example, a subset of system functionality) is selected and developed, then another increment, and so on. The selection of the first increment to be developed is based on risk, with the highest priority risks first. To address the selected risk(s), choose a subset of use cases. Develop the minimal set of use cases that will allow objective verification (that is, through a set of executable tests) of the risks that you have chosen. Then, select the next increment to address the next-highest risk, and so on.
  • Iterative development produces the architecture first, allowing integration to occur “ as the verification activity ” of the design phase and allowing design flaws to be detected and resolved earlier in the lifecycle. Continuous integration throughout the project replaces the “ big bang ” integration at the end of a project. Iterative development also provides much better insight into quality, because of system characteristics that are largely inherent in the architecture. For example, performance, fault tolerance, and maintainability are tangible earlier in the process. Thus, issues are still correctable without jeopardizing target costs and schedules.
  • A report from the Standish Group confirms that a distinct minority of software development projects is completed on-time and on-budget. In their report, the success rate was only 28 percent, while challenged projects (operational, but late and over-budget) accounted for 49 percent. Cancelled projects accounted for 23 percent. These failures are attributed to lack of executive management support, lack of user involvement, inexperienced project managers, ill-defined business objectives, poor scope management, no standard software infrastructure, no firm basic requirements, no formal methodology, and unreliable estimates. (Source: Chaos 2001 Report, http://www.standishgroup.com).
  • A report from the Standish Group confirms that a distinct minority of software development projects is completed on time and on budget. In their report, the success rate was only 16.2%, while challenged projects (operational, but late and over budget) accounted for 52.7%. Impaired (canceled) projects accounted for 31.1%. These failures are attributed to incorrect requirements definition from the start of the project and poor requirements management throughout the development lifecycle. (Source: Chaos Report , http://www.standishgroup.com) Aspects of requirements management: Analyze the problem Understand user needs Define the system Manage scope Refine the system definition Manage changing requirements
  • Software architecture is the development product that gives the highest return on investment with respect to quality, schedule, and cost, according to the authors of Software Architecture in Practice (Len Bass, Paul Clements & Rick Kazman [1998] Addison-Wesley). The Software Engineering Institute (SEI) has an effort underway called the Architecture Tradeoff Analysis (ATA) Initiative to focus on software architecture, a discipline much misunderstood in the software industry. The SEI has been evaluating software architectures for some time and would like to see architecture evaluation in wider use. By performing architecture evaluations, AT&T reported a 10 percent productivity increase (from news@sei, Vol. 1, No. 2).
  • Architecture is a part of Design. It is about making decisions on how the system will be built. But it is not all of the design. It stops at the major abstractions, or, in other words, the elements that have some pervasive and long-lasting effect on system performance and ability to evolve. A software system ’ s architecture is perhaps the most important aspect that can be used to control the iterative and incremental development of a system throughout its lifecycle. The most important property of an architecture is resilience – flexibility in the face of change. To achieve it, architects must anticipate evolution in both the problem domain and the implementation technologies to produce a design that can gracefully accommodate such changes. Key techniques are abstraction, encapsulation, and object-oriented Analysis and Design. The result is that applications are fundamentally more maintainable and extensible. Software architecture is the development product that gives the highest return on investment with respect to quality, schedule, and cost, according to the authors of Software Architecture in Practice (Len Bass, Paul Clements, and Rick Kazman [1998] Addison-Wesley). The Software Engineering Institute (SEI) has an effort underway called the Architecture Tradeoff Analysis (ATA) Initiative that focuses on software architecture, a discipline much misunderstood in the software industry. The SEI has been evaluating software architectures for some time and would like to see architecture evaluation in wider use. As a result of performing architecture evaluations, AT&T reported a 10% productivity increase (from news@sei, Vol. 1, No. 2). You can encourage a brief discussion at this point. A single requirement, such as throughput or fault tolerance, affects almost every design decision made on a system. For example, if a transportation system (such as for trains) is being built, it is likely to have a “no single point of failure” requirement that must be in every developer’s mind every step of the way. Many architectural mechanisms will be developed to accommodate that single requirement. If you can get some students to describe their architectural challenges, this point will be driven home more effectively.
  • Definition of a (Software) Component: RUP Definition : A nontrivial, nearly independent, and replaceable part of a system that fulfills a clear function in the context of a well-defined architecture. A component conforms to and provides the physical realization of a set of interfaces. UML Definition : A physical, replaceable part of a system that packages implementation, and conforms to and provides the realization of a set of interfaces. A component represents a physical piece of implementation of a system, including software code (source, binary, or executable) or equivalents, such as scripts or command files. Because students vary in how familiar they are with the concept of architecture applied to software, it is best to get a sense of this from the students before beginning this section. If they are fairly unfamiliar, it helps to use the analogy of buildings or civil engineering. As a building becomes more complex , good architecture becomes more critical. The longer you want the building to be useful, the more effort and expense you should put into the architecture. I n both cases, the choice of architect is critical.
  • A model is a simplification of reality that provides a complete description of a system from a particular perspective. We build models so that everyone can understand the system to be built. Models are built for complex systems because we cannot comprehend any such system in its entirety. You may wish to lead a discussion about models and why we build models in general. For example, before building a bridge, the architect builds a model and has it reviewed. We build models because some projects are so complex that no one can understand all of the details. A model leaves out all the details that are unimportant. It facilitates our understanding of the larger issues.
  • A model is a simplification of reality that provides a complete description of a system from a particular perspective. We build models so that we can better understand the system we are building. We build models of complex systems because we cannot comprehend any such system in its entirety. Modeling is important because it helps the development team visualize, specify, construct, and document the structure and behavior of system architecture. Using a standard modeling language such as the UML (the Unified Modeling Language), different members of the development team can communicate their decisions unambiguously to one another. Using visual modeling tools facilitates the management of these models, letting you hide or expose details as necessary. Visual modeling also helps you maintain consistency among system artifacts: its requirements, designs, and implementations. In short, visual modeling helps improve a team ’ s ability to manage software complexity. Visual modeling for software is analogous to blueprints for construction.
  • In building a visual model of a system, many different diagrams are needed to represent different views of the system. The UML provides a rich notation for visualizing models. This includes the following key diagrams: Use-case diagrams to illustrate user interactions with the system Class diagrams to illustrate logical structure Object diagrams to illustrate objects and links Component diagrams to illustrate physical structure of the software Deployment diagrams to show the mapping of software to hardware configurations Activity diagrams to illustrate flows of events State Machine diagrams to illustrate behavior Interaction diagrams (that is, Communication and Sequence diagrams) to illustrate behavior This is not all of the UML diagrams, just a representative sample. The UML provides a graphical language for representing models but provides little or no guidance on when and how to use these diagrams. This is an area in which the RUP helps. It describes the kinds of project artifacts needed, including diagrams, and puts them in the context of an overall project plan.
  • Quality , as used within RUP, is defined as "The characteristic of having demonstrated the achievement of producing a product which meets or exceeds agreed-upon requirements, as measured by agreed-upon measures and criteria, and is produced by an agreed-upon process." Given this definition, achieving quality is not simply "meeting requirements" or producing a product that meets user needs and expectations. Quality also includes identifying the measures and criteria (to demonstrate the achievement of quality) and the implementation of a process to ensure that the resulting product has achieved the desired degree of quality (and can be repeated and managed). In many organizations, software testing accounts for 30 percent to 50 percent of software development costs. Yet most people believe that software is not well-tested before it is delivered. This contradiction is rooted in two clear facts. First, testing software is enormously difficult. The different ways a particular program can behave are almost infinite. Second, testing is typically done without a clear methodology and without the required automation or tool support. While the complexity of software makes complete testing an impossible goal, a well-conceived methodology and use of state-of-the-art tools can greatly improve the productivity and effectiveness of the software testing. Do not assume that verifying quality and testing are synonymous. While testing is used to do the bulk of quality verification, there are other techniques.
  • Quality , as used within the RUP, is defined as “ The characteristic of having demonstrated the achievement of producing a product which meets or exceeds agreed-upon requirements, as measured by agreed-upon measures and criteria, and is produced by an agreed-upon process." Given this definition, achieving quality is not simply “ meeting requirements" or producing a product that meets user needs and expectations. Quality also includes identifying the measures and criteria (to demonstrate the achievement of quality) and the implementation of a process to ensure that the resulting product has achieved the desired degree of quality (and can be repeated and managed). This principle is driven by a fundamental and well-known property of software development: It is a lot less expensive to correct defects during development than to correct them after deployment. Tests for key scenarios ensure that all requirements are properly implemented. Poor application performance hurts as much as poor reliability. Verify software reliability by checking for memory leaks and bottlenecks. Test every iteration by automating testing. Inception, Elaboration, Construction, and Transition are all RUP terms that will be discussed shortly. Many people remember Barry Boehm’s groundbreaking work in Software Economics , where he quantified the relative expense to fix a bug at different times in the development lifecycle. Be cautious, however, since his work was based on the waterfall model, not an iterative development model. The iterative model fundamentally changes how and when we test.
  • Functional testing verifies that a system executes the required use-case scenarios as intended. Functional tests may include the testing of features, usage scenarios, and security. Usability testing evaluates the application from the user ’ s perspective. Usability tests focus on human factors, aesthetics, consistency in the user interface,   online and context-sensitive help, wizards and agents, user documentation, and   training materials. Reliability testing verifies that the application performs reliably and is not prone to failures during execution (crashes, hangs, memory leaks). Effective reliability testing requires specialized tools. Reliability tests include integrity, structure, stress, contention, and volume tests. Performance testing checks that the target system works functionally and reliably under production load. Performance tests include benchmark tests, load tests, and performance profile tests. Supportability testing verifies that the application can be deployed as intended. Supportability tests include installation and configuration tests. This is the FURPS model of dimensions of quality presented in RUP. See the RUP for details about all these types of tests. Be prepared to define and discuss all.
  • In each iteration, automated tests are created that test the requirements addressed in that iteration. As new requirements are added in subsequent iterations, new tests are generated and run. At times, a requirement may be changed in a later iteration. In that case, the tests associated with the changed requirement may be modified or simply regenerated by an automated tool. It is important to start automating test in the earliest iterations. Some people think that you do not need to automate testing until the later iterations when requirements are pretty stable. Even if you expect that the requirements…and hence the tests, are still unstable, it is still more efficient to automate.
  • As indicated earlier, you cannot stop change from being introduced into a project. However, you must control how and when changes are introduced into project artifacts and who introduces the changes. As well, you must synchronize change across development teams and locations. Unified Change Management (UCM) is Rational Software's approach to managing change in software system development, from requirements to release. Control of change is especially important in an iterative project. Artifacts are generally produced incrementally. At the end of each iteration, another increment is put under configuration control. Otherwise, no progress is made, and iterations do not converge on a complete and consistent system. We are not just talking about changes to source code, but also to requirements, models, documents, plans, and all development artifacts.
  • Change Request Management (CRM) addresses the organizational infrastructure required to assess the cost and schedule impact of a requested change to the existing product. CRM addresses the workings of a Change Review Team or Change Control Board. Configuration Status Accounting (Measurement) is used to describe the “ state ” of the product based on the type, number, rate, and severity of defects found and fixed during the course of product development. Metrics derived under this aspect, either through audits or raw data, are useful in determining the overall completeness of the project. Configuration Management (CM) describes the product structure and identifies its constituent configuration items that are treated as single versionable entities in the configuration management process. CM deals with defining configurations, building and labeling, and collecting versioned artifacts into constituent sets and maintaining traceability between these versions. Change Tracking describes what is done to components for what reason and at what time. It serves as the history and rationale of changes. It is quite separate from assessing the impact of proposed changes as described under Change Request Management. Version Selection is to ensure that the right versions of configuration items are selected for change or implementation. Version selection relies on a solid foundation of “ configuration identification. ” Software Manufacture covers the need to automate the steps to compile, test, and package software for distribution.
  • Establishing a secure workspace for each developer provides isolation from changes made in other workspaces and control of all software artifacts — models, code, documents and so forth. A key challenge to developing software-intensive systems is the need to cope with multiple developers, organized into different teams, possibly at different sites, all working together on multiple iterations, releases, products, and platforms. In the absence of disciplined control, the development process rapidly degrades into chaos. Progress can come to a stop. Three common problems that result are: Simultaneous update : When two or more roles separately modify the same artifact, the last one to make changes destroys the work of the others. Limited notification : When a problem is fixed in shared artifacts, some of the developers are not notified of the change. Multiple versions : With iterative development, it would not be unusual to have multiple versions of an artifact in different stages of development at the same time. For example, one release is in customer use, one is in test, and one is still in development. If a problem is identified in any one of the versions, the fix must be propagated among all of them. If possible, use examples from your experience to illustrate what can go wrong when doing parallel development without adequate controls. For example, describe two programmers making simultaneous updates to the same component, or a very important test failing in front of a customer because the wrong version of the test case was run.
  • Unified Change Management (UCM) is “ the Rational software approach ” to managing change in software system development, from requirements to release. UCM spans the development lifecycle, defining how to manage change to requirements, design models, documentation, components, test cases, and source code. One of the key aspects of the UCM model is that it unifies the activities used to plan and track project progress and the artifacts undergoing change. You cannot stop change from being introduced into a project; however, you must control how and when changes are introduced into project artifacts, and who introduces those changes. You must also synchronize changes across development teams and locations. Unified Change Management (UCM) is the Rational Software approach to managing change in software system development, from requirements to release. Regarding support for UCM in the RUP: The CM concepts described in UCM are covered in the RUP by the following workflow details: Create Project CM Environments Change and Deliver Configuration Items Manage Baselines and Releases UCM does not cover the RUP activities described in these workflows: Monitor and Report Configuration Status Manage Change Requests The activities described in the RUP workflow detail — Plan Project Configuration and Change Control — are at a higher level of abstraction than the notion of a project described in UCM. However, UCM does cover the fact that policies need to be set, and that there is a CM process to be followed to ensure that all project artifacts are maintained under configuration control.
  • Why have a process? It provides guidelines for efficient development of quality software It reduces risk and increases predictability It promotes a common vision and culture It captures and institutionalizes Best Practices The Rational Unified Process (RUP) is a generic business process for object-oriented software engineering. It describes a family of related software-engineering processes sharing a common structure and a common process architecture. It provides a disciplined approach to assigning tasks and responsibilities within a development organization. Its goal is to ensure the production of high-quality software that meets the needs of its end users within a predictable schedule and budget. The RUP captures the Best Practices in modern software development in a form that can be adapted for a wide range of projects and organizations. The UML provides a standard for the artifacts of development (semantic models, syntactic notation, and diagrams): the things that must be controlled and exchanged. But the UML is not a standard for the development process . Despite all of the value that a common modeling language brings, you cannot achieve successful development of today ’ s complex systems solely by the use of the UML. Successful development also requires employing an equally robust development process, which is where the RUP comes in.
  • Examples: The dynamic structure (phases and iterations) of the Rational Unified Process creates the basis of iterative development. The Project Management discipline describes how to set up and execute a project using phases and iterations. Within the Requirements discipline, the Use-case model and the risk list determine what functionality you implement in an iteration. The workflow details of the Requirements discipline show the activities and artifacts that make requirements management possible. The iterative approach allows you to progressively identify components and to decide which one to develop, which one to reuse, and which one to buy. The Unified Modeling Language (UML) used in the process represents the basis of visual modeling and has become the de facto modeling language standard. The focus on software architecture allows you to articulate the structure: the components, the ways in which they integrate, and the fundamental mechanisms and patterns by which they interact.
  • It can be very difficult to explain what a process is, if the students are not already familiar with it. An informal example most people can relate to is the process of balancing a checkbook at the end of the month. Most of us have developed a process we use that includes the same steps every month. It shortens the time required to accomplish the task and ensures that we do not forget any steps. The same applies to a software-engineering process. We want it to be repeatable and to ensure that all required tasks are accomplished when required. Of course, a software-engineering process is much more complex than balancing a checkbook, and there is a tremendous amount of information contained in the RUP.
  • During Inception, we define the scope of the project: what is included and what is not. We do this by identifying all the actors and use cases, and by drafting the most essential use cases (typically 20% of the complete model). A business plan is developed to determine whether resources should be committed to the project. During Elaboration, we focus on two things: getting a good grasp of the requirements (80% complete) and establishing an architectural baseline. If we have a good grasp of the requirements and the architecture, we can eliminate a lot of the risks, and we will have a good idea of how much work remains to be done. We can make detailed cost and resource estimates at the end of Elaboration. During Construction, we build the product in several iterations up to a beta release. During Transition, we move the product to the end user and focus on end-user training, installation, and support. The amount of time spent in each phase varies. For a complex project with many technical unknowns and unclear requirements, Elaboration may include three to five iterations. For a simple project, where requirements are known and the architecture is simple, Elaboration may include only a single iteration. The Student Notes are quite extensive. There is no need to go into that much detail in class. The important thing is to understand how the RUP uses phases to organize the lifecycle. You can also mention that we deliberately chose names that do not match the waterfall names (analysis, design, implementation, and test) to emphasize that they are not the same as the waterfall phases. Some ways of describing the phases in common terminology: Inception — Bid and proposal Elaboration — Building blueprints Construction — I think I’m done. Transition — How do users react?
  • This slide illustrates how phases and iterations (the time dimension) relate to the development activities (the discipline dimension). The relative size of each color area in the graph indicates how much of the activity is performed in each phase or iteration. Each iteration involves activities from all disciplines. The relative amount of work related to the disciplines changes between iterations. For instance, during late Construction, the main work is related to Implementation and Test, and very little work on Requirements is done. Note that requirements are not necessarily complete by the end of Elaboration. It is acceptable to delay the analysis and design of well-understood portions of the system until Construction because they are low in risk. This is a brief summary of the RUP disciplines: Business Modeling – Encompasses all modeling techniques you can use to visually model a business. Requirements – Defines what the system should do. Analysis & Design – Shows how the system's use cases will be realized in implementation. Implementation – Implements software components that meet quality standards. Test – Integrates and tests the system. Deployment - Provides the software product to the end-user. Configuration & Change Management – Controls and tracks changes to artifacts. Project Management – Ensures tasks are scheduled, allocated and completed in accordance with project schedules, budgets and quality requirements. Environment – Defines and manages the environment in which the system is being developed.
  • 1 gioi thieu httt

    1. 1. TỔNG QUAN VỀ HỆ THỐNG THÔNG TIN
    2. 2. TỔNG QUAN VỀ HỆ THỐNG THÔNG TIN <ul><li>Khái niệm cơ bản về hệ thống (System) </li></ul><ul><li>Tổ chức (Organization) </li></ul><ul><li>Dữ liệu (Data) và thông tin (information) </li></ul><ul><li>Thông tin và các mức ra quyết định quản lý (Management decision making) </li></ul><ul><li>Định nghĩa hệ thống thông tin (Information Systems) </li></ul><ul><li>Phân loạI IS </li></ul><ul><ul><li>Các IS phân loại theo mức quản lý tổ chức. </li></ul></ul>
    3. 3. Khái niệm cơ bản về hệ thống <ul><li>&quot;Một hệ thống là một tập hợp các thành phần liên quan với nhau và phối hợp hoạt động cùng với nhau nhằm đạt được một mục tiêu cụ thể&quot; (Lee) </li></ul>System A Subsystem B Subsystem C Subsystem E Subsystem D Boundary Interface Environment of System A
    4. 4. Tổ chức (Organization) <ul><li>Tổ chức là một hệ thống </li></ul><ul><ul><li>Tổ chức kinh tế: xí nghiệp, công ty, … </li></ul></ul><ul><ul><li>Tổ chức xã hội: bệnh viện, câu lạc bộ, … </li></ul></ul>Môi trường hoạt động của tổ chức Sales IT HRI Purchasing Training
    5. 5. Dữ liệu và thông tin <ul><li>Dữ liệu (data): </li></ul><ul><ul><li>&quot;Data is the raw input from which information is provided” (Lucey) </li></ul></ul><ul><ul><li>Là các dữ kiện, các sự kiện, các giao dịch thô, rời rạc, ... </li></ul></ul><ul><li>Thông tin (information): </li></ul><ul><ul><li>“ Information is data that have been processed in such a way as to be useful to the recipient.” (Lucey) </li></ul></ul><ul><li>Thông tin là tài nguyên của tổ chức, và có vai trò quan trọng quyết định sự thành công của tổ chức. </li></ul><ul><ul><li>Thông tin được tạo ra và truy xuất ngày càng tăng </li></ul></ul><ul><ul><li>Yêu cầu quản lý thông tin hiệu quả. </li></ul></ul><ul><ul><li>Xử lý để tạo ra các thông tin mới có giá trị hơn </li></ul></ul>
    6. 6. Information Systems (IS) <ul><li>Một hệ thống thông tin: </li></ul><ul><ul><li>Là các phương tiện có thể nhận dữ liệu (input), lưu trữ và xử lý dữ liệu, để tạo ra thông tin (output) cho mục đích hỗ trợ ra quyết định. </li></ul></ul><ul><ul><li>Có thể xử lý bằng tay hoặc máy tính. </li></ul></ul><ul><li>Hệ thống thông tin của tổ chức gồm: </li></ul><ul><ul><li>Một cơ sở thông tin (information base) mà bao gồm một hay nhiều nguồn thông tin khác; </li></ul></ul><ul><ul><li>Một tập các xử lý mà được thực hiện bởi người hay máy để truy xuất, cập nhập và xử lý thông tin. </li></ul></ul><ul><ul><li>Ví dụ: Một hệ thống thư viện có cơ sở thông tin là sách, loại sách, …; các xử lý là tìm, mượn, trả sách, … </li></ul></ul>
    7. 7. Hệ thống thông tin tự động hóa <ul><li>Hệ thống thông tin tự động hóa (Computerized Information Systems) bao gồm: </li></ul><ul><ul><li>Một hay nhiều cơ sở dữ liệu (databases) hay tập tin (files) lưu trữ cở sở thông tin. </li></ul></ul><ul><ul><li>Một hay nhiều chương trình ứng dụng (Application programs) để truy xuất và cập nhật cơ sở thông tin bằng máy tính. </li></ul></ul><ul><ul><li>Một hay nhiều giao diện người dùng (user interface) cho các nhóm người dùng khác nhau. </li></ul></ul><ul><li>Computerized Information System = Databases + Applications + Interfaces </li></ul>
    8. 8. <ul><li>Thông tin cần thiết cho doanh nghiệp và giúp ra quyết định ở nhiều mức quản lý khác nhau trong tổ chức </li></ul>Thông tin và các cấp quản lý Anthony’s Pyramid: cấu trúc quản lý của tổ chức Operational Tactical Strategic Large time horizon Small time horizon Summary data Detail data Unstructured problems Structured problems
    9. 9. Transaction Processing Systems Banking Systems EPOS Systems Healthcare Systems Insurance Systems Leisure Industry
    10. 10. Real-Time Systems Automated Production Control Control Systems Security Systems
    11. 11. Management Information Systems Decision Support Systems Office Automation Systems Knowledge Based Systems Executive Information Systems
    12. 12. Best Practices of Software Engineering
    13. 13. Objectives: Best Practices <ul><li>Identify symptoms of software development problems. </li></ul><ul><li>Explain the Best Practices. </li></ul><ul><li>Present the Rational Unified Process (RUP) within the context of the Best Practices. </li></ul>
    14. 14. Mục đích của công nghệ phần mềm <ul><li>Nhằm tạo ra sản phẩm phần mềm có chất lượng </li></ul><ul><ul><li>Với ít nỗ lực (tiến trình phát triển dễ dàng) </li></ul></ul><ul><ul><li>Với ít chi phí và thời gian </li></ul></ul><ul><li>Chất lượng phần mềm (Quality Software) bao gồm: </li></ul><ul><ul><li>Tính đáng tin cậy (Reliable) </li></ul></ul><ul><ul><li>Tính dễ dùng (Reusable) </li></ul></ul><ul><ul><li>Tinh tế (Robust): có các chức năng hiệu quả </li></ul></ul><ul><ul><li>Dễ bảo trì (Maintainable) </li></ul></ul><ul><ul><li>Tính Hiệu quả (Efficient) </li></ul></ul><ul><ul><li>Thân thiện người dùng (Userfriendly) </li></ul></ul><ul><ul><li>… </li></ul></ul>
    15. 15. Bản chất việc phát triển phần mềm <ul><li>Phần mềm là sản phẩm của hoạt động phát triển một cách sáng tạo của các “nghệ sĩ lành nghề” </li></ul><ul><ul><li>Phần mềm được phát triển, chứ không phải sản xuất. </li></ul></ul><ul><ul><li>Ngay cả với công nghệ thành phần (Component technology), phần mềm được xây dựng bằng cách lắp ghép các thành phần thì xử lý lắp ghép này cũng là nghệ thuật. </li></ul></ul><ul><li>Cho bất kỳ hệ thống nào, luôn cần phải tạo ra một mô hình quan niệm của giải pháp cuối cùng thỏa mãn các yêu cầu của khách hàng. </li></ul><ul><ul><li>Đó là kết quả của nhiệm vụ phân tích yêu cầu và thiết kế hệ thống. </li></ul></ul><ul><ul><li>Độc lập với cài đặt. </li></ul></ul>
    16. 16. Con người liên quan (Stakeholders) <ul><li>Khách hàng (Customers): Users và System owners </li></ul><ul><ul><li>Các nguyên nhân dẫn đến thất bại của dự án phần mềm liên quan đến khách hàng: </li></ul></ul><ul><ul><li>Yêu cầu khách hàng bị hiểu sai và hay thu thập không đầy đủ </li></ul></ul><ul><ul><li>Yêu cầu khách hàng thay đổi quá thường xuyên. </li></ul></ul><ul><ul><li>Khách hàng không giao đầy đủ các tài nguyên cho dự án. </li></ul></ul><ul><ul><li>Khách hàng không hợp tác với người phát triển. </li></ul></ul><ul><ul><li>Mong đợi không thực tế của khách hàng. </li></ul></ul><ul><ul><li>Khách hàng không cần đến hệ thống nữa. </li></ul></ul><ul><li>Người phát triển (Developers): Analysts, Designers, Programmers </li></ul><ul><ul><li>“ Thiết kế tốt được tạo từ những nhà thiết kế tốt” </li></ul></ul>
    17. 17. Symptoms of Software Development Problems <ul><li>User or business needs not met </li></ul><ul><li>Requirements not addressed </li></ul><ul><li>Modules not integrating </li></ul><ul><li>Difficulties with maintenance </li></ul><ul><li>Late discovery of flaws </li></ul><ul><li>Poor quality of end-user experience </li></ul><ul><li>Poor performance under load </li></ul><ul><li>No coordinated team effort </li></ul><ul><li>Build-and-release issues </li></ul>
    18. 18. Trace Symptoms to Root Causes Needs not met Requirements churn Modules don’t fit Hard to maintain Late discovery Poor quality Poor performance Colliding developers Build-and-release Insufficient requirements Ambiguous communications Brittle architectures Overwhelming complexity Undetected inconsistencies Poor testing Subjective assessment Waterfall development Uncontrolled change Insufficient automation Symptoms Root Causes Best Practices Ambiguous communications Undetected inconsistencies Develop Iteratively Manage Requirements Use Component Architectures Model Visually (UML) Continuously Verify Quality Manage Change Modules do not fit Model Visually (UML) Continuously Verify Quality
    19. 19. Best Practices Reinforce Each Other Best Practices Develop Iteratively Manage Requirements Use Component Architectures Model Visually (UML) Continuously Verify Quality Manage Change Validates architectural decisions early on Addresses complexity of design/implementation incrementally Measures quality early and often Evolves baselines incrementally Ensures users are involved as requirements evolve
    20. 20. Practice 1: Develop Iteratively Best Practices Process Made Practical Develop Iteratively Manage Requirements Use Component Architectures Model Visually (UML) Continuously Verify Quality Manage Change
    21. 21. Waterfall Development Characteristics <ul><li>Delays confirmation of critical risk resolution. </li></ul><ul><li>Measures progress by assessing work-products that are poor predictors of time-to-completion. </li></ul><ul><li>Delays and aggregates integration and testing. </li></ul><ul><li>Precludes early deployment. </li></ul><ul><li>Frequently results in major unplanned iterations. </li></ul>Code and Test Design Subsystem Integration System Test Waterfall Process Requirements Analysis Planning
    22. 22. Iterative Development Characteristics <ul><li>Resolves major risks before making large investments. </li></ul><ul><li>Enables early user feedback. </li></ul><ul><li>Makes testing and integration continuous. </li></ul><ul><li>Focuses project short-term objective milestones. </li></ul><ul><li>Makes possible deployment of partial implementations. </li></ul>T I M E Iteration 1 Iteration 2 Iteration 3 P R D C I T P R D C I T P R D C I T
    23. 23. Develop Iteratively <ul><li>Iterative development produces an executable </li></ul>1. Initial Planning 2. Planning 3. Requirements 4. Analysis & Design 5. Implementation 7. Deployment 6. Test 8. Evaluation Management Environment (on-going) Each iteration results in an executable release
    24. 24. Risk Profiles Time Risk Waterfall Risk Iterative Risk Risk Reduction
    25. 25. Practice 2: Manage Requirements Best Practices Process Made Practical Develop Iteratively Manage Requirements Use Component Architectures Model Visually (UML) Continuously Verify Quality Manage Change
    26. 26. Managing Requirements <ul><li>Ensures that you </li></ul><ul><ul><li>solve the right problem </li></ul></ul><ul><ul><li>build the right system </li></ul></ul><ul><li>by taking a systematic approach to </li></ul><ul><ul><li>Understanding the problem. </li></ul></ul><ul><ul><li>Eliciting, organizing, and documenting the requirements. </li></ul></ul><ul><ul><li>Managing the changing requirements of a software application. </li></ul></ul>
    27. 27. Practice 3: Use Component Architectures Best Practices Process Made Practical Develop Iteratively Manage Requirements Use Component Architectures Model Visually (UML) Continuously Verify Quality Manage Change
    28. 28. Use Component Architectures <ul><li>Software architecture needs to be: </li></ul>Component-based Resilient <ul><ul><li>Reuse or customize components </li></ul></ul><ul><ul><li>Select from commercially available components </li></ul></ul><ul><ul><li>Evolve existing software incrementally </li></ul></ul><ul><ul><li>Meets current and future requirements </li></ul></ul><ul><ul><li>Improves extensibility </li></ul></ul><ul><ul><li>Enables reuse </li></ul></ul><ul><ul><li>Encapsulates system dependencies </li></ul></ul>
    29. 29. Purpose of a Component-Based Architecture <ul><li>Basis for reuse </li></ul><ul><ul><li>Component </li></ul></ul><ul><ul><li>Architecture </li></ul></ul><ul><li>Basis for project management </li></ul><ul><ul><li>Planning </li></ul></ul><ul><ul><li>Staffing </li></ul></ul><ul><ul><li>Delivery </li></ul></ul><ul><li>Intellectual control </li></ul><ul><ul><li>Manage complexity </li></ul></ul><ul><ul><li>Maintain integrity </li></ul></ul>System- software Middleware Business- specific Application- specific Component-based architecture with layers
    30. 30. Practice 4: Model Visually (UML) Best Practices Process Made Practical Develop Iteratively Manage Requirements Use Component Architectures Model Visually (UML) Continuously Verify Quality Manage Change
    31. 31. Model Visually (UML) <ul><li>Captures structure and behavior </li></ul><ul><li>Shows how system elements fit together </li></ul><ul><li>Keeps design and implementation consistent </li></ul><ul><li>Hides or exposes details as appropriate </li></ul><ul><li>Promotes unambiguous communication </li></ul><ul><ul><li>The UML provides one language for all practitioners. </li></ul></ul>
    32. 32. Visual Modeling with the Unified Modeling Language Dynamic Diagrams Multiple views Precise syntax and semantics Activity Diagrams Models Static Diagrams Sequence Diagrams Communication Diagrams State Machine Diagrams Deployment Diagrams Component Diagrams Object Diagrams Class Diagrams Use-Case Diagrams
    33. 33. Activity Diagram – Lược đồ hoạt động <ul><li>Activity diagrams được dùng để miêu tả dòng công việc </li></ul><ul><li>Ví dụ: Một lược đồ hoạt động trình bày một quy trình nghiệp vụ đơn giản để xuất hóa đơn và thanh toán </li></ul>
    34. 34. Use Case Diagram Use Case Actor Use Case Diagram B <<extend>> A <<include>> a1 Generalization
    35. 35. Class Diagram Personal Customer creditCard# Customer name address creditRating() {if Order.customer.creditRating is &quot;poor&quot; then Order.isPrepaid must be true} Employee Corporate Customer contactName creditRating creditLimit remind() billForMonth() 0..1 0..n 0..1 0..n sales rep Order dateReceived isPrepaid number : String price : Money dispatch() close() 1 0..n 1 0..n Product Order Line quantity : Integer price : Money isSatisfied : Boolean 1..n 1 1..n 1 1 0..n 1 0..n
    36. 36. Sequence Diagram – Lược đồ tuần tự
    37. 37. Collaboration Diagram – Lược đồ cộng tác
    38. 38. Statechart Diagram – Lược đồ trạng thái
    39. 39. Component Diagram – Lược đồ thành phần <ul><li>Lược đồ thành phần trình bày hệ thống được tổ chức thành các thành phần cộng tác với nhau như thế nào; </li></ul><ul><li>Các thành phần được xây dựng từ các đối tượng </li></ul>Call Centre Interface Order Management Customer Management Database Management
    40. 40. Practice 5: Continuously Verify Quality Best Practices Process Made Practical Develop Iteratively Manage Requirements Use Component Architectures Model Visually (UML) Continuously Verify Quality Manage Change
    41. 41. Continuously Verify Quality Cost Transition Construction Elaboration Inception <ul><li>Cost to Repair Software </li></ul><ul><li>Cost of Lost Opportunities </li></ul><ul><li>Cost of Lost Customers </li></ul>Software problems are 100 to 1000 times more costly to find and repair after deployment
    42. 42. Test Dimensions of Quality Reliability Test the application for consistent and predictable behavior. Performance Test online response under average and peak loading. Functionality Test the accurate workings of each usage scenario. Usability Test the application from the perspective of convenience to end-user. Supportability Test the ability to maintain and support the application under production use.
    43. 43. Test Each Iteration UML Model and Implementation Tests Iteration 1 Test Suite 1 Iteration 2 Test Suite 2 Iteration 3 Test Suite 3 Test Suite 4 Iteration 4
    44. 44. Practice 6: Manage Change Best Practices Process Made Practical Develop Iteratively Manage Requirements Use Component Architectures Model Visually (UML) Continuously Verify Quality Manage Change
    45. 45. Change Request Management Concepts Change requests come from many sources throughout the product lifecycle. Help Desk User input Coders input Testers input Customer and User input Marketing New Feature New Requirement Bug Approved Decision Process Change Control Board (CCB) Single Channel for Approval Change Request (CR) Reqt Design Code Test Maint Weinberg, ‘95
    46. 46. Manage Change <ul><li>To avoid confusion, have: </li></ul><ul><ul><li>Secure workspaces for each developer </li></ul></ul><ul><ul><li>Automated integration/build management </li></ul></ul><ul><ul><li>Parallel development </li></ul></ul>Workspace Management Process Integration Parallel Development Build Management Configuration Management is more than just check-in and check-out
    47. 47. Manage Change (continued) <ul><li>Unified Change Management (UCM) involves: </li></ul><ul><ul><li>Management across the lifecycle </li></ul></ul><ul><ul><ul><li>System </li></ul></ul></ul><ul><ul><ul><li>Project management </li></ul></ul></ul><ul><ul><li>Activity-based management </li></ul></ul><ul><ul><ul><li>Tasks </li></ul></ul></ul><ul><ul><ul><li>Defects </li></ul></ul></ul><ul><ul><ul><li>Enhancements </li></ul></ul></ul><ul><ul><li>Progress tracking </li></ul></ul><ul><ul><ul><li>Charts </li></ul></ul></ul><ul><ul><ul><li>Reports </li></ul></ul></ul>
    48. 48. Rational Unified Process Implements Best Practices Develop Iteratively Manage Requirements Use Component Architectures Model Visually (UML) Continuously Verify Quality Manage Change Best Practices Process Made Practical
    49. 49. Achieving Best Practices <ul><li>Iterative approach </li></ul><ul><li>Guidance for activities and artifacts </li></ul><ul><li>Process focus on architecture </li></ul><ul><li>Use cases that drive design and implementation </li></ul><ul><li>Models that abstract the system </li></ul>
    50. 50. A Team-Based Definition of Process <ul><li>A process defines Who is doing What , When , and How , in order to reach a certain goal. </li></ul>New or changed requirements New or changed system Software Engineering Process
    51. 51. Process Structure - Lifecycle Phases <ul><li>The Rational Unified Process has four phases: </li></ul><ul><ul><li>Inception – Define the scope of the project </li></ul></ul><ul><ul><li>Elaboration – Plan the project; specify features and baseline architecture </li></ul></ul><ul><ul><li>Construction – Build the product </li></ul></ul><ul><ul><li>Transition – Transition the product into the end-user community </li></ul></ul>Time Inception Elaboration Construction Transition
    52. 52. Bringing It All Together: The Iterative Approach Disciplines group activities logically. In an iteration, you walk through all disciplines.
    53. 53. Summary <ul><li>Best Practices guide software engineering by addressing root causes. </li></ul><ul><li>Best Practices reinforce each other. </li></ul><ul><li>Process guides a team on who does what, when, and how. </li></ul><ul><li>The Rational Unified Process is a means of achieving Best Practices. </li></ul>

    ×