CHAPTER I SOFTWARE AND SOFTWARE ENGINEERING software engineering is to be applied.An action (e.g.,architectural design)encom passes a set of tasks that produce a major work product(e.g.,an architectural model). A task focuses on a small,but well-defined objective (e.g.,conducting a unit test)that produces a tangible outcome. In the context of softwa to build d computer software.Rathe r,it is s an a ple doing the work (the software team)to pick and choose the appropriate set of work actions and tasks.The intent is always to deliver software in a timely manner and with sufficient quality to satisfy those who have sponsored its creation and those who will use it. 1.3.1 The Process Framework A process framework establishes the foundation for a complete software engineering process by identifying a small number of framework activities that are applicable to all software projects,regardless of their size or complexity.In addition,the process set of umbrella tha are applicable s the k for software engineering encom- passes five activities: Communication.Before any technical work can commence,it is critically important to communicate and collaborate with the customer (and other stakeholders).3 The intent is to understand stakeholders'objectives for the project and to gather require- ments that help define software features and functions Planning Any complicated journey can be simplified if a map exists.A softwa ourney,and the planning activit creat csa“map”that helps guide the team as it makes the journey.The map-called a sofrware project plan- defines the software engineering work by describing the technical tasks to be con- ducted,the risks that are likely.the resources that will be required,the work products to be produced.and a work schedule. Modeling.Whether you're a landscaper.a bridge builder.an aeronautical engineer er or an a rch with models e ever day Yo eate a "sker that yo e big picture -what it k like turally.how the constituent parts fit together.and many oth If required.you refine the sketch into greater and greater detail in an effort to better understand the problem and how you're going to solve it.A software engineer does the same thing by creating models to better understand software requirements and the design that will achieve those requirements. Construction.What you design must be built.This activity combines code genera r man ual or automated)and the testing that is required to uncover errors ir 8A stakeholder is anyone who has a stake in the successful out upport people.ar .If you don'to your stakeholders.you knowv where the stak
10 CHAPTER 1 SOFTWARE AND SOFTWARE ENGINEERING software engineering is to be applied. An action (e.g., architectural design) encompasses a set of tasks that produce a major work product (e.g., an architectural model). A task focuses on a small, but well-defined objective (e.g., conducting a unit test) that produces a tangible outcome. In the context of software engineering, a process is not a rigid prescription for how to build computer software. Rather, it is an adaptable approach that enables the people doing the work (the software team) to pick and choose the appropriate set of work actions and tasks. The intent is always to deliver software in a timely manner and with sufficient quality to satisfy those who have sponsored its creation and those who will use it. 1.3.1 The Process Framework A process framework establishes the foundation for a complete software engineering process by identifying a small number of framework activities that are applicable to all software projects, regardless of their size or complexity. In addition, the process framework encompasses a set of umbrella activities that are applicable across the entire software process. A generic process framework for software engineering encompasses five activities: Communication. Before any technical work can commence, it is critically important to communicate and collaborate with the customer (and other stakeholders).8 The intent is to understand stakeholders’ objectives for the project and to gather requirements that help define software features and functions. Planning. Any complicated journey can be simplified if a map exists. A software project is a complicated journey, and the planning activity creates a “map” that helps guide the team as it makes the journey. The map—called a software project plan— defines the software engineering work by describing the technical tasks to be conducted, the risks that are likely, the resources that will be required, the work products to be produced, and a work schedule. Modeling. Whether you’re a landscaper, a bridge builder, an aeronautical engineer, a carpenter, or an architect, you work with models every day. You create a “sketch” of the thing so that you’ll understand the big picture—what it will look like architecturally, how the constituent parts fit together, and many other characteristics. If required, you refine the sketch into greater and greater detail in an effort to better understand the problem and how you’re going to solve it. A software engineer does the same thing by creating models to better understand software requirements and the design that will achieve those requirements. Construction. What you design must be built. This activity combines code generation (either manual or automated) and the testing that is required to uncover errors in the code. 8 A stakeholder is anyone who has a stake in the successful outcome of the project—business managers, end users, software engineers, support people, and so forth. Rob Thomsett jokes that, “a stakeholder is a person holding a large and sharp stake. . . . If you don’t look after your stakeholders, you know where the stake will end up
CHAPTER 1 SOFTWARE AND SOFTWARE ENGINEERING Deployment.The software(as a complete entity or as a partially completed incre- ment)is delivered to the customer who evaluates the delivered product and provides feedback based on the evaluation These five generic framework activities can be used during the development of small simple programs the creation of Web for the engineering of large. complex computer-based systems.The details of the software process will be quite different in each case,but the framework activities remain the same. For many software projects,framework activities are applied iteratively as a project progresses That is communication plapning.modeling construction and d are applied rep produces a software nt that provide sstakeholders with a subse tof overal software features and functionality.As each increment is produced,the software becomes more and more complete. 1.3.2 Umbrella Activities Software engineering process framework activities are complemented by a number of umbrella activities.In general.umbrella activities are applied throughout a software Software project tracking and control.Allows the software team to asses progress against the project plan and take any necessary action to maintain the schedule Risk management.Assesses risks that may affect the outcome of the project or the quality of the product. Technical reviews.Assess software engineering work products in an effort to uncover and before they are propagated to the next activity. Measurement.Defines and collects process,project,and product measures that assist the team in delivering software that meets stakeholders'needs;can be used in conjunction with all other framework and umbrella activities. Software configuration management.Manages the effects of change throughout the software process. Reusability management.Defines criteria for work product reuse (including software components)and establishes mechanisms to achieve reusable components. Work product preparation and production.Encompasses the activities required to create work products such as models,documents,logs,forms,and lists. Each of these umbrella activities is discussed in detail later in this book. 1.3.3 Process Adaptation Previously in this section,we noted that the software ess is not a rigid tha mus dogmatically by as oftware team ther,it should agile and adaptable (to the problem.to the project,to the team.and to the organizational
CHAPTER 1 SOFTWARE AND SOFTWARE ENGINEERING 11 Deployment. The software (as a complete entity or as a partially completed increment) is delivered to the customer who evaluates the delivered product and provides feedback based on the evaluation. These five generic framework activities can be used during the development of small, simple programs; the creation of Web applications; and for the engineering of large, complex computer-based systems. The details of the software process will be quite different in each case, but the framework activities remain the same. For many software projects, framework activities are applied iteratively as a project progresses. That is, communication, planning, modeling, construction, and deployment are applied repeatedly through a number of project iterations. Each iteration produces a software increment that provides stakeholders with a subset of overall software features and functionality. As each increment is produced, the software becomes more and more complete. 1.3.2 Umbrella Activities Software engineering process framework activities are complemented by a number of umbrella activities. In general, umbrella activities are applied throughout a software project and help a software team manage and control progress, quality, change, and risk. Typical umbrella activities include: Software project tracking and control. Allows the software team to assess progress against the project plan and take any necessary action to maintain the schedule. Risk management. Assesses risks that may affect the outcome of the project or the quality of the product. Software quality assurance. Defines and conducts the activities required to ensure software quality. Technical reviews. Assess software engineering work products in an effort to uncover and remove errors before they are propagated to the next activity. Measurement. Defines and collects process, project, and product measures that assist the team in delivering software that meets stakeholders’ needs; can be used in conjunction with all other framework and umbrella activities. Software configuration management. Manages the effects of change throughout the software process. Reusability management. Defines criteria for work product reuse (including software components) and establishes mechanisms to achieve reusable components. Work product preparation and production. Encompasses the activities required to create work products such as models, documents, logs, forms, and lists. Each of these umbrella activities is discussed in detail later in this book. 1.3.3 Process Adaptation Previously in this section, we noted that the software engineering process is not a rigid prescription that must be followed dogmatically by a software team. Rather, it should be agile and adaptable (to the problem, to the project, to the team, and to the organizational
CHAPTER I SOFTWARE AND SOFTWARE ENGINEERING culture).Therefore,a process adopted for one project might be significantly different than a process adopted for another project.Among the differences are: .Overall flow of activities,actions,and tasks and the interdependencies among them Degree to which actions and tasks are defined within each framework activity Degree to which work products are identified and required .Manner in which quality assurance activities are applied Manner in which project tracking and control activities are applied .Overall degree of detail and rigor with which the process is described .Degree to which the customer and other stakeholders are involved with the projec Level of autonomy given to the software team Degree to which team organization and roles are prescribed In Part One of this book,we examine software process in considerable detail. 1.4 SOFTWARE ENGINEERING PRACTICE In Section 1.3,we introduced a generic software process model composed of a set of activities that establish a fran for oftw Generic fram work activitie communication,planni ng,mo construction,and deployment-and umbrella activities establish a skeleton architecture for software engineering work.But how does the practice of software engineering fit in?In the sections that follow,you'll gain a basic understanding of the generic concepts and principles that apply to framework activities. 1.4.1 The Essence of Practice In the classic book How to Solve It,written before modern computers existed,George Polva IPol45]outlined the essence of problem solving.and consequently.the essence of software engineering practice: 1.Understand the problem (communication and analysis) 2.Plan a solution (modeling and software design). 3.Carry out the plan (code generation). 4.Examine the result for accuracy(testing and quality assurance). In the context of software engineering,these commonsense steps lead to a series of essential questions [adapted from Pol45]: Understand the Problem.It's sometimes difficult to admit,but most of us suffer from hubris when we're presented w ith a probler We listen for a few seconds and
12 CHAPTER 1 SOFTWARE AND SOFTWARE ENGINEERING culture). Therefore, a process adopted for one project might be significantly different than a process adopted for another project. Among the differences are: ∙ Overall flow of activities, actions, and tasks and the interdependencies among them ∙ Degree to which actions and tasks are defined within each framework activity ∙ Degree to which work products are identified and required ∙ Manner in which quality assurance activities are applied ∙ Manner in which project tracking and control activities are applied ∙ Overall degree of detail and rigor with which the process is described ∙ Degree to which the customer and other stakeholders are involved with the project ∙ Level of autonomy given to the software team ∙ Degree to which team organization and roles are prescribed In Part One of this book, we examine software process in considerable detail. 1.4 So f t wa r e Eng i n e e r i ng Pr ac t i c e In Section 1.3, we introduced a generic software process model composed of a set of activities that establish a framework for software engineering practice. Generic framework activities—communication, planning, modeling, construction, and deployment—and umbrella activities establish a skeleton architecture for software engineering work. But how does the practice of software engineering fit in? In the sections that follow, you’ll gain a basic understanding of the generic concepts and principles that apply to framework activities.9 1.4.1 The Essence of Practice In the classic book How to Solve It, written before modern computers existed, George Polya [Pol45] outlined the essence of problem solving, and consequently, the essence of software engineering practice: 1. Understand the problem (communication and analysis). 2. Plan a solution (modeling and software design). 3. Carry out the plan (code generation). 4. Examine the result for accuracy (testing and quality assurance). In the context of software engineering, these commonsense steps lead to a series of essential questions [adapted from Pol45]: Understand the Problem. It’s sometimes difficult to admit, but most of us suffer from hubris when we’re presented with a problem. We listen for a few seconds and 9 You should revisit relevant sections within this chapter as we discuss specific software engineering methods and umbrella activities later in this book
CHAPTER 1 SOFTWARE AND SOFTWARE ENGINEERING then think,Oh yeah,I understand,let's get on with solving this thing.Unfortunately. understanding isn't always that easy.It's worth spending a little time answering a fev simple questic Who has a stake in the solution to the problem?That is,who are the stake holders? ·What are the uknowns?What data.functions and features are required to Can the problem be compartmentalized?Is it possible to represent smaller problems that may be easier to understand? Can the problem be represented graphically?Can an analysis model be created? Plan the Solution.Now you understand the problem (or so you think),and you can't wait to begin coding.Before you do,slow down just a bit and do a little design: .Have you seen similar problems before?Are there patterns that are recogniz able in a p otential solu Is there ex ist software that implements the data,functions,and features that are required Has a similar problem been solved?If so,are elements of the solution reusable? Can subproblems be defined?If so,are solutions readily apparent for the subproblems? Can you represent a solution in a manner that leads to effective implementation? Can a design model be created? Carry Out the Plan.The design you've created serves as a road map for the system you want to build.There may be unexpected detours,and it's possible that you'll discover an even better route as you go.but the "plan"will allow you to proceed without getting lost. Does the solution conform to the plan?Is source code traceable to the desigr model? Is each component part of the solution ect?Has the design and code been eviewed. pro or be tter,have correctness pro ofs bee applied to the algorithm? Examine the Result.You can't be sure that your solution is perfect,but you can be sure tha nat you've designed a sufficient number of tests to uncover as many errors as possible. Is it possible to test each component part of the solution?Has a reasonable testing strategy been implemented? Does the solution produce results that conform to the data,functions,and features that are required?Has the software been validated against all stake- holder requirements? It shouldn't surprise you that much of this appro ach is common sense.In fact,it's e onable to state that a commonsense approach to software engineering will never lead you astray
CHAPTER 1 SOFTWARE AND SOFTWARE ENGINEERING 13 then think, Oh yeah, I understand, let’s get on with solving this thing. Unfortunately, understanding isn’t always that easy. It’s worth spending a little time answering a few simple questions: ∙ Who has a stake in the solution to the problem? That is, who are the stakeholders? ∙ What are the unknowns? What data, functions, and features are required to properly solve the problem? ∙ Can the problem be compartmentalized? Is it possible to represent smaller problems that may be easier to understand? ∙ Can the problem be represented graphically? Can an analysis model be created? Plan the Solution. Now you understand the problem (or so you think), and you can’t wait to begin coding. Before you do, slow down just a bit and do a little design: ∙ Have you seen similar problems before? Are there patterns that are recognizable in a potential solution? Is there existing software that implements the data, functions, and features that are required? ∙ Has a similar problem been solved? If so, are elements of the solution reusable? ∙ Can subproblems be defined? If so, are solutions readily apparent for the subproblems? ∙ Can you represent a solution in a manner that leads to effective implementation? Can a design model be created? Carry Out the Plan. The design you’ve created serves as a road map for the system you want to build. There may be unexpected detours, and it’s possible that you’ll discover an even better route as you go, but the “plan” will allow you to proceed without getting lost. ∙ Does the solution conform to the plan? Is source code traceable to the design model? ∙ Is each component part of the solution provably correct? Has the design and code been reviewed, or better, have correctness proofs been applied to the algorithm? Examine the Result. You can’t be sure that your solution is perfect, but you can be sure that you’ve designed a sufficient number of tests to uncover as many errors as possible. ∙ Is it possible to test each component part of the solution? Has a reasonable testing strategy been implemented? ∙ Does the solution produce results that conform to the data, functions, and features that are required? Has the software been validated against all stakeholder requirements? It shouldn’t surprise you that much of this approach is common sense. In fact, it’s reasonable to state that a commonsense approach to software engineering will never lead you astray
CHAPTER I SOFTWARE AND SOFTWARE ENGINEERING 1.4.2 General Principles The dictionary defines the word principle as"an important underlying law or assump tion required in a system of thought."Throughout this book we'll discuss principles at many different levels of abstraction.Some focus on software engineering as a whole.others consider a specific generic framework activity (e.g.communication). and still others focus on software engineerin g actions (e.g chitectural design)or technical tasks (e.g.creating a usage scenar principles help you establish a mind-set for solid software engineering practice.They are important for that reason. David Hooker[Hoo96]has proposed seven principles that focus on software engi neering practice as a whole.They are reproduced in the following paragraphs: The First Principle:The Reason It All Exists A software system exists for one reason:to provide value to its users.All deci- sions should be made with this in mind.Before specifying a system requirement. before noting a piece of system functionality,before determining the hardware plat- forms or development processes,ask yourself questions such as:"Does this add real value to the system?"If the answer is no,don't do it.All other principles support this one The Second Principle:KISS (Keep It Simple.Stupid!) There are many factors to consider in any design effort.All design should be as simple as possible,but no simpler.This facilitates having a more easily understood and easily maintained system.This is not to say that features should be discarded in the name of simplicity.Indeed,the more elegant designs are usually the simpler Simple do not mean “quick nd dir ."It ofte take s a lot of t work ove ons to simplify the design.The payoff is software that i more maintainable and less error-prone The Third Principle:Maintain the Visior A clear vision is essential to the success of a software project.Without concep tual integrity.a system threatens to bece me a patchwork of i held together by the wrong kind of screws Comp isin vision of a software system weakens and will eventually break even the well designed systems.Having an empowered architect who can hold the vision and enforce compliance helps ensure a very successful software project. The Fourth Principle:What You Produce.Others Will Consume Abways specify.design.doctmer and implement knowing som one else will have to understand what you are doing.The audience for any product of software development is potentially large.Specify with an eye to the users.Design,keeping the implementers in mind.Code with concern for those that must maintain and extend the system.Someone may have to debug the code you write,and that makes them a user of your code.Making their iob easier adds value to the system. erns for these prin
14 CHAPTER 1 SOFTWARE AND SOFTWARE ENGINEERING 1.4.2 General Principles The dictionary defines the word principle as “an important underlying law or assumption required in a system of thought.” Throughout this book we’ll discuss principles at many different levels of abstraction. Some focus on software engineering as a whole, others consider a specific generic framework activity (e.g., communication), and still others focus on software engineering actions (e.g., architectural design) or technical tasks (e.g., creating a usage scenario). Regardless of their level of focus, principles help you establish a mind-set for solid software engineering practice. They are important for that reason. David Hooker [Hoo96] has proposed seven principles that focus on software engineering practice as a whole. They are reproduced in the following paragraphs:10 The First Principle: The Reason It All Exists A software system exists for one reason: to provide value to its users. All decisions should be made with this in mind. Before specifying a system requirement, before noting a piece of system functionality, before determining the hardware platforms or development processes, ask yourself questions such as: “Does this add real value to the system?” If the answer is no, don’t do it. All other principles support this one. The Second Principle: KISS (Keep It Simple, Stupid!) There are many factors to consider in any design effort. All design should be as simple as possible, but no simpler. This facilitates having a more easily understood and easily maintained system. This is not to say that features should be discarded in the name of simplicity. Indeed, the more elegant designs are usually the simpler ones. Simple does not mean “quick and dirty.” It often takes a lot of thought and work over multiple iterations to simplify the design. The payoff is software that is more maintainable and less error-prone. The Third Principle: Maintain the Vision A clear vision is essential to the success of a software project. Without conceptual integrity, a system threatens to become a patchwork of incompatible designs, held together by the wrong kind of screws . . . Compromising the architectural vision of a software system weakens and will eventually break even the welldesigned systems. Having an empowered architect who can hold the vision and enforce compliance helps ensure a very successful software project. The Fourth Principle: What You Produce, Others Will Consume Always specify, design, document, and implement knowing someone else will have to understand what you are doing. The audience for any product of software development is potentially large. Specify with an eye to the users. Design, keeping the implementers in mind. Code with concern for those that must maintain and extend the system. Someone may have to debug the code you write, and that makes them a user of your code. Making their job easier adds value to the system. 10 Reproduced with permission of the author [Hoo96]. Hooker defines patterns for these principles at http://c2.com/cgi/wiki?SevenPrinciplesOfSoftwareDevelopment