• Tidak ada hasil yang ditemukan

Software Engineering Theory and Practice

N/A
N/A
Philip

Academic year: 2023

Membagikan "Software Engineering Theory and Practice"

Copied!
783
0
0

Teks penuh

The book has an annotated bibliography that points to many of the major works in software engineering. The chapter concludes by applying some of the methods to two common examples.

SOFTWARE ENGINEERING

WHAT IS SOFTWARE ENGINEERING?

Once we have analyzed the problem, we must construct our solution from components that address the different aspects of the problem. Thus, any problem-solving technique must have two parts: analyzing the problem to determine its nature, and then synthesizing a solution based on our analysis.

PROBLEM

SOLUTION

HOW SUCCESSFUL HAVE WE BEEN?

Any hacker can write code to make something work, but it takes the skill and understanding of a professional software engineer to produce code that is robust, easy to understand and maintain, and that does its job the way most efficient and effective possible. In addition, software has enabled us to do things never imagined in the past: microsurgery, multimedia education, robotics and more.

TERMINOLOGY FOR DESCRIBING BUGS

  • WHAT IS GOOD SOFTWARE?

Despite some stunning successes and the general acceptance of software as a fact of life, there is still much room for improvement in the quality of the software we produce. Half of the cost of fixing bugs discovered during testing and maintenance comes from bugs much earlier in the system's life.

PERSPECTIVES ON QUALITY

  • WHO DOES SOFTWARE ENGINEERING?
  • A SYSTEMS APPROACH
  • AN ENGINEERING APPROACH
  • MEMBERS OF THE DEVELOPMENT TEAM
  • HOW HAS SOFTWARE ENGINEERING CHANGED?

We can also describe the activities in the system in relation to the interactions of the units. Once the development team is comfortable with the functionality and quality of the system, attention is directed to the customer.

FIGURE 1.6 Terms included in industry definition of return on investment.
FIGURE 1.6 Terms included in industry definition of return on investment.

CHANGES IN SOFTWARE

INFORMATION SYSTEMS EXAMPLE

In this book, we highlight aspects of the problem and its solutions; Robertsons book shows detailed methods for capturing and analyzing system requirements. The shaded oval is the Piccadilly system, which treats us as our example of an information system; the boundary of the system is simply the circumference of the oval.

REAL-TIME EXAMPLE

The failure of the rocket and its subsequent destruction raises many questions about software quality. In fact, the committee of inquiry formed to investigate the cause and cure of the disaster noted that.

WHAT THIS CHAPTER MEANS FOR YOU

The position of the launcher and its movements in space are measured by the inertial reference system (SRI). You can use abstraction and measurement to help identify essential aspects of the problem and the solution.

WHAT THIS CHAPTER MEANS FOR YOUR DEVELOPMENT TEAM

You can keep the system boundary in mind so that your solution does not overlap the related systems that interact with what you are building.

WHAT THIS CHAPTER MEANS FOR RESEARCHERS

TERM PROJECT

Loan Arranger is an application that allows an FCO analyst to select a package of loans that match the investor's investment characteristics. The loans that FCO purchases for investment and resale are collectively known as the loan portfolio. A loan analyst can add, view, update or delete loan information about the lenders and pool of loans in the portfolio.

KEY REFERENCES

When an investor specifies investment criteria, the system selects the optimal bundle of loans that meet the criteria. Although the system will allow some advanced optimizations, such as selecting the best bundle of loans from a subset of those available (for example, from all loans in Massachusetts, rather than from all loans available), the system will still allow an analyst to manually select loans in a bundle for the customer. We can summarize this information by saying that the Loan Arranger system gives a loan analyst access to information about mortgages (home loans, described here simply as "loans") purchased by FCO from multiple lending institutions with the intention of repackaging the loans for sale to other investors .

EXERCISES

What issues should be addressed during software development to prevent such problems in the future. Give an example of the error that leads to the error in the requirements; design; the code. Give an example of an error in the requirements that leads to failure; design flaw leading to failure; an error in the test data that causes the error.

THE MEANING OF PROCESS

A process uses resources subject to a set of constraints (such as a schedule) and produces intermediate and final products. A process can be defined as a hierarchy of processes organized in such a way that each sub-process has its own process model. For example, the process may require us to verify our design components before coding begins.

SOFTWARE PROCESS MODELS

The waterfall model has been used to prescribe software development activities in various contexts. The waterfall model can be very useful in helping developers determine what to do. Many problems with the waterfall model have been discussed in the literature, and two of them are summarized in Sidebar 2.1.

DRAWBACKS OF THE WATERFALL MODEL

Zave (1984) proposes a process model that allows developers and customers to examine the requirements and their implications early in the development process, where they can discuss and resolve some of the uncertainty. They focus on customer collaboration rather than contract negotiation and thereby involve the customer in key aspects of the development process. Collective ownership: In XP, any developer can make a change to any part of the system while it is being developed.

FIGURE 2.2 The software development process in reality.
FIGURE 2.2 The software development process in reality.

WHEN IS EXTREME TOO EXTREME?

  • TOOLS AND TECHNIQUES FOR PROCESS MODELING

As we investigate software engineering in later chapters, we'll examine each development activity to see what it involves and find out what tools and techniques make us more effective and productive. There are many choices for modeling tools and techniques, once you decide what you want to capture in your process model; we have seen several modeling approaches in our descriptions of models in the previous section. In particular, your choice of annotation depends on what you want to capture in your model. Notations range from textual ones that express processes as functions, to graphical ones that describe processes.

COLLECTIONS OF PROCESS MODELS

In other words, we want to describe a model of the process and then see how software shows us how resources flow through activities to become outputs. For example, if the fraction of experienced staff increases from a quarter to half of the people assigned to the project, we would expect average potential productivity to increase as well. For example, Abdel-Hamid's software development model contains more than 100 causal links; Figure 2.14 shows an overview of the relationships he defined.

TABLE 2.1 Artifact Definition Form for Artifact “CAR” (Lai 1991)
TABLE 2.1 Artifact Definition Form for Artifact “CAR” (Lai 1991)

PROCESS PROGRAMMING

  • PRACTICAL PROCESS MODELING

Several researchers report that, properly used, process modeling offers great benefits in understanding processes and revealing inconsistencies. The top half of the figure defines the class that we will see in Chapter 3. Differences in skill, experience, work habits, understanding of the customer's needs, and a host of other factors can dramatically increase variability. The coordination of a web of creative intellectual tasks does not appear to be greatly improved by current implementations of process programming, because the most important source of coordination is to ensure that all the interacting agents share the same mental model of how the system should function ” ( Curtis et al. 1987).

SUBPROCESSWORKCENTER 1

  • INFORMATION SYSTEMS EXAMPLE
  • REAL-TIME EXAMPLE
  • WHAT THIS CHAPTER MEANS FOR YOU
  • WHAT THIS CHAPTER MEANS FOR YOUR DEVELOPMENT TEAM
  • WHAT THIS CHAPTER MEANS FOR RESEARCHERS
  • TERM PROJECT
  • KEY REFERENCES
  • EXERCISES
  • TRACKING PROGRESS

The repository maintained by the Loan Organizer contains information about all the loans in the portfolio. What are the advantages and disadvantages of using the model for each of the process models described in this chapter. By working forward through the graph in this way, we can calculate the earliest start time and slack for each of the activities.

TABLE 2.2 Artifact Definition Form for Artifact “Risk”
TABLE 2.2 Artifact Definition Form for Artifact “Risk”

SYSTEM PLANNING

SYSTEM DESIGN

  • PROJECT PERSONNEL

As we study each of the major development tasks in the following chapters, we will describe the project team members who perform those tasks. Differences can be critical, not only for planning evaluation, but also for project success. In general, if a project has non-workers, then there are pairs of people who may need to communicate and possible teams that can be formed to work on smaller parts of the project.

FIGURE 3.9 Communication paths on a project.
FIGURE 3.9 Communication paths on a project.

MAKE MEETINGS ENHANCE PROJECT PROGRESS

Let's say Claude is your client and you are preparing a project status presentation for him. Helping the boss is a deputy, whose main task is to replace the main programmer when necessary. However, if most of the team members are introverts, a lead developer team may not be the best structure for the project.

FIGURE 3.10 Work styles.
FIGURE 3.10 Work styles.

STRUCTURE VS. CREATIVITY

  • EFFORT ESTIMATION

For example, if requirements may change as development continues, the project has a degree of uncertainty. We need to determine how many days of staff effort will be needed to complete the project. the cost component with the greatest degree of uncertainty. But assessment should be done repeatedly throughout the life cycle; as aspects of the project change, the estimate may.

CAUSES OF INACCURATE ESTIMATES

  • RISK MANAGEMENT

The accuracy of the prediction is thus based on the competence, experience, objectivity and perception of the estimator. A weighted sum of the 29 factors was then used to generate an effort estimate from the basic equation. For each item in the table, the project is scored from 0 (not present) to 5 (very important), depending on the project manager's assessment.

FIGURE 3.12 Changes in estimation accuracy as project progresses (Boehm et al. 1995).
FIGURE 3.12 Changes in estimation accuracy as project progresses (Boehm et al. 1995).

BOEHM’S TOP TEN RISK ITEMS

  • THE PROJECT PLAN
  • PROCESS MODELS AND PROJECT MANAGEMENT
  • INFORMATION SYSTEMS EXAMPLE
  • REAL-TIME EXAMPLE
  • WHAT THIS CHAPTER MEANS FOR YOU
  • WHAT THIS CHAPTER MEANS FOR YOUR DEVELOPMENT TEAM
  • WHAT THIS CHAPTER MEANS FOR RESEARCHERS
  • TERM PROJECT
  • KEY REFERENCES
  • EXERCISES

Event related loss. The event must create a situation in which something negative happens to the project: loss of time, quality, money, control, understanding, etc. Vision was used to “enroll” related programs so that they all shared common goals. Similarly, we can rate the price range screen as "simple", the availability screen as "medium", and the sales report as "medium". We then use Table 3.11 to assign a complexity level of 1 to simple displays, 2 to medium displays, and 5 to medium reports; a summary of our estimates is shown in Table 3.15.

FIGURE 3.15 Steps in risk management (Rook 1993).
FIGURE 3.15 Steps in risk management (Rook 1993).

WHY ARE REQUIREMENTS IMPORTANT?

  • THE REQUIREMENTS PROCESS
  • REQUIREMENTS ELICITATION

These implementation-specific descriptions are not considered requirements (unless requested by the customer). The goal of the requirements phase is to understand the customer's problems and needs. Once the requirements are well understood, we move into the specification phase, where we decide which parts of the required behavior will be implemented in the software. The end result of the requirements process is a software specification (SRS), which is used to communicate to other software developers (designers, testers, maintainers) how the final product should behave.

FIGURE 4.1 Process for capturing the requirements.
FIGURE 4.1 Process for capturing the requirements.

AGILE REQUIREMENTS MODELING

  • TYPES OF REQUIREMENTS

Each stakeholder has a particular view of the system and how it should work, and often these views conflict. A process constraint is a limitation on the techniques or resources that can be used to build the system. How easy should it be to port the system from one platform (computer, operating system) to another.

TABLE 4.1 How Users and Developers View Each Other (Scharer 1990)
TABLE 4.1 How Users and Developers View Each Other (Scharer 1990)

MAKING REQUIREMENTS TESTABLE

  • CHARACTERISTICS OF REQUIREMENTS
  • MODELING NOTATIONS

In contrast, the concept of an entry event may lie outside the scope of the system. The conceptual model thus helps to tie several points of view and descriptions of the requirements together. A transition action restricts which tokens in the input slots can enable the transition and specifies the values ​​of the output tokens.

FIGURE 4.3 Requirements vs. Specification.
FIGURE 4.3 Requirements vs. Specification.

Gambar

FIGURE 1.6 Terms included in industry definition of return on investment.
FIGURE 1.10 Layers of a water-monitoring system.
FIGURE 1.11 The roles of the development team.
FIGURE 1.12 The key factors that have changed software development.
+7

Referensi

Dokumen terkait