Software Engineering: A Practitioner's Approach
Software Engineering:A Practitioner's ApproachCopyright 1996, 2001R.S. Pressman & Associates, Inc.For University Use OnlyMay be reproduced ONLY for student use atthe university levelWhen used in conjunction with SoftwareEngineering: A Practitioner's Approach.Any other reproduction or use is expresslyprohibited.
Chapter1The ProductCHAPTER OVERVIEW AND COMMENTSThe goal of this chapter is to introduce the notion of software asa product designed and built by software engineers. Software isimportant because it is used by a great many people in society.Software engineers have a moral and ethical responsibility toensure that the software they design does no serious harm toany people. Software engineers tend to be concerned with thetechnical elegance of their software products. Customers tend tobe concerned only with whether or not a software productmeets their needs and is easy to use.1.1The Evolving Role of SoftwareThe main point of this section is that the primary purpose ofsoftware is that of information transformer. Software is used toproduce, manage, acquire, modify, display, and transmitinformation anywhere in the world. The days of the loneprogrammer are gone. Modern software is developed by teamsof software specialists. Yet, the software developer's concernshave remained the same. Why does software take so long tocomplete? Why does it cost so much to produce? Why can't allerrors be found and removed before software is delivered to thecustomer?1.2SoftwareSoftware is not like the artifacts produced in most otherengineering disciplines. Software is developed it is notmanufactured in the classical sense. Building a software productis more like constructing a design prototype. Opportunities forreplication without customization are not very common.Software may become deteriorate, but it does not wear out. Thechief reason for software deterioration is that many changes aremade to a software product over its lifetime. As changes are
made, defects may be inadvertently introduced to otherportions of the software that interact with the portion that waschanged.1.3Software: A Crisis on the HorizonMany people have written about the "software developmentcrisis". There seems to be an inordinate fascination with thespectacular software failures and a tendency to ignore the largenumber of successes achieved by the software industry.Software developers are capable of producing software thefunctions properly most of the time. The biggest problem facingmodern software engineers is trying to figure out how toproduce software fast enough to meet the growing demand formore products, while also having to maintain a growingvolume of existing software.1.4Software MythsThe myths presented in this section provide a good source ofmaterial for class discussion. Managers need to understand thatbuying hardware and adding people does not spontaneouslysolve all software development problems. Customers need tounderstand that computer software does not make all theirother problems go away. If the customer can not define his orher needs clearly, it is not possible to build a software productto meet these needs. If a customer does not have definedbusiness processes without computer support, buildingcomputer software will not create these processes automatically.Software engineers must be committed to the concept of doingthings right the first time. Software quality does not happen onits own after a product is finished. Quality must be built intoevery portion of the software development process.PROBLEMS AND POINTS TO PONDER1.1. Classic examples include the use of "digitalautomobile dashboards" to impart a high tech, highquality images. Appliances that "think;" the broadarray of consumer electronics; personal computers(today, differentiated more by their software functionthan the hardware), industrial instrumentation ated by software.
1.2. The apprentice/artist culture of the 1950s and1960s worked fine for single person, well constrainedprojects. Today, applications are more complex, teamswork on large projects, and software blished in the early days dies hard, leading morethan a little resistance to more disciplined methods.In addition (see Chapter 29), the new generation ofWeb application developers is repeating many of thesame mistakes that programmer made during the circa1965.1.3. This is a good problem for classroom discussion(time permitting). Rather than focusing on cliche'ridden (albeit important) issues of privacy, ght" and how software can help to exacerbateor remedy it. Another interesting possibility is touse Neumann's "Risks" column in SEN to key discussion.You might also consider new attempts at ctiveentertainment, virtual reality, e-commerce, etc.1.5. There are literally dozens of real lifecircumstances to choose from. For example, softwareerrors that have caused major telephone networks tofail, failures in avionics that have contributed toplane crashes, computer viruses (e.g., Michaelangelo)that have caused significant economic losses. Attackson major e-commerce sites.1.6. The two broadest categories encompass risksassociated with economic loss and risks to the wellbeing of people. You might suggest that each studentselect five risks (culled from the sources noted) andpresent them to the class. Encourage them to look forhumorous as well as serious risks.1.7. To be honest, most professors do not assignpapers as part of software engineering courses thatuse SEPA. Instead, a term project (or a number ofsomewhat smaller projects) are assigned. However, youmight consider discussing software engineering issuesas they relate to the topics noted in this problem.1.8Another way to characterize this problem is tosuggest that each student describe a software myththat he or she believed that has subsequently beendispelled. From the student's point of view, mythswill likely be driven by programming projects thatthey've attempted earlier in their career. To givethis problem a contemporary feel, you might considerthe myths that have evolved around the development ofWeb-based applications.
Chapter2The ProcessCHAPTER OVERVIEW AND COMMENTSThis chapter discusses several process models used byprofessional software developers to manage large-scalesoftware projects. No software process works well for everyproject. However, every project needs to conform to somesystematic process in order to manage software developmentactivities that can easily get out of control. Software processeshelp to organize the work products that need to be producedduring a software development project. Ultimately the bestindicator of how well a software process has worked is thequality of the deliverables produced. A well-managed processwill produce high quality products on time and under budget.2.1Software Engineering - A Layered TechnologySoftware engineering encompasses a process, the managementof activities, technical methods, and use of tools to developsoftware products. Software is engineered by applying threedistinct phases (definition, development, and support).Students need to understand that maintenance involves morethan fixing bugs.2.2The Software ProcessThis section discusses the concept of a software processframework and provides a brief overview of the SoftwareEngineering Institute Capability Maturity Model. It is importantto emphasize that the Capability Maturity Model does notspecify what process model needs to be used for a given projector organization. Rather, it provides a means of assessing howwell an organization's processes allow them to complete andmanage new software projects.2.3Software Process Models
The terms "software process model" and "software engineeringparadigm" are used interchangeably in the literature. Thischapter presents overviews of several software process models.It is easy for students to become so lost in the details of thevarious process models that they fail to see the features themodels have in common with each other. Another difficultystudents have is their belief that each phase of a process isperformed completely independently of the other phases. Thereality is that there tends to be lots overlap among the phases.2.4The Linear Sequential ModelThe linear sequential model is also known as the "classic lifecycle" or "waterfall model". System development proceedsthough the phases (analysis, design, coding, testing, support) inorder. This is a good model to use when requirements are wellunderstood. If a phase must be revisited in this model, processfailure is indicated (more thorough requirements analysis isneeded).2.5The Prototyping ModelThis model is good to use when the customer has legitimateneeds, but is not able to articulate the details at the start of theproject. A small mock-up of a working system is developed andpresented to the customer. Sometimes this first system isdiscarded and sometimes it is extended based on the customer'sfeedback.2.6The RAD ModelThe rapid application deployment model is a high-speedadaptation of the linear sequential model. Project requirementsmust be well understood and the project scope tightlyconstrained. Developers are often able to use component-basedconstruction techniques to build a fully functional system in ashort time period.2.7Evolutionary ModelsThe two most important models in this section are theincremental model and the spiral model. The incremental modelcombines elements of the linear sequential model appliedrepetitively with the iterative philosophy of the prototypingmodel. Each increment produces a working version of a
software product with increasing functionality. There is nothrowaway code. The spiral model also combines the iterativenature of prototyping with the systematic control found in thelinear sequential model. An essential component of the spiralmodel is that assessment of both management and technicalrisks is performed as each incremental release is completed.2.8Component-Based DevelopmentObject-based technologies provide the technical framework forcomponent-based software engineering. The component-baseddevelopment (CBD) model incorporates many of the iterativecharacteristics of the spiral model. The main difference is that inCBD the emphasis is on composing solutions from prepackagedsoftware components or classes. This CBD emphasizes softwarereusability. The unified software development process is anexample of CBD that has been proposed for industrial use. Theunified modeling language (UML) is used to define thecomponents and interfaces used in the unified softwaredevelopment process.2.9The Formal Methods ModelFormal methods in software development require the use ofrigorous mathematical notation to specify, design, and verifycomputer-based systems. Mathematical proof is used to verifythe correctness of a system (not empirical testing). Cleanroomsoftware engineering is an example of this approach. Whileformal methods have the potential to produce defect-freesoftware, the development of formal models is both timeconsuming and expensive.2.10 Fourth Generation TechniquesThis is a broad class of techniques. The general idea is that asoftware tool is used to describe a system in manner understoodby the customer using a specialized design language orgraphical notation. In the ideal case, the tool then generatessource code from this system description that can be compiledinto a running system. The running system then needs to betested and refined using other software engineering processes.There is some risk that the customer is not able to describe thesystem in sufficient detail or that the initial system will bedeployed without sufficient testing.
Section 2.12 uses a short essay by Margaret Davis toput process and product issues into perspective. If you’reteaching a graduate course, I’d recommend PhillipHoward’s The Death of Common Sense, as outside reading onthe failures of a wholly process-oriented mind set.PROBLEMS AND POINTS TO PONDER2.1. You might suggest that students use the FurtherReadings and Information Sources section of Chapter 8for pointers.2.2. The support phase is applied differently forembedded software. In most cases, embedded software isdefined and developed, but once it is placed in itshost environment, it is not likely to change until anew release of the product occurs.2.3.The latest SEI information can be obtained at:http://www.sei.cmu.edu/2.4. In each case status quo, problem definition,technical development, and solution integration areapplied at a different levels of abstraction. ts level would entail many meetings withmarketing and even potential end-users;“technicaldevelopment” at the product requirements level woulddemand the creation of a product specification;“solution integration” would require detailed reviewagainst customer requirements and modifications. At alower level of abstraction (e.g., generate code .)the nature of these activities would change, movingaway from customer related information and towardimplementation specific information.2.5. Assign this problem as is if the majority ofyour class is composed of industry practitioners. Ifyour students are "green," suggest a project scenarioand ask the students to identify the appropriateparadigm. The key here is to recognize that the "best"paradigm is a function of the problem, the customer,the environment, the people doing the work and manyother factors. My choice — all thing being equal — isthe evolutionary approach.2.6. Software applications that are relatively easyto prototype almost always involve human-machineinteraction and/or heavy computer graphics. ping are certain classes of mathematicalalgorithms, subset of command driven systems and otherapplications where results can be easily examinedwithout real-time interaction. Applications that aredifficult to prototype include control and ications and embedded software.
2.7. Any software project that has significantfunctionality that must be delivered in a very tight(too tight) time frame is a candidate for lity in increments. Example: a sophisticatedsoftware product that can be released to themarketplace with only partial functionality—new andimproved versions to follow!2.8Any project in which tight time-lines anddelivery dates preclude delivery of full functionalityis a candidate for the incremental model. Also anysoftware product in which partial functionality maystill be saleable is a candidate.2.9. As work moves outward on the spiral, the productmoves toward a more complete state and the level ofabstraction at which work is performed is reduced(i.e., implementation specific work accelerates as wemove further from the origin).2.10. I would suggest postponing this problem untilChapter 27 is assigned, unless you do not intend toassign it. In that case, it can serve to introduce theimportance of reuse.2.11. Stated simply, the concurrent process modelassumes that different parts of a project will be adifferent stages of completeness, and therefore,different software engineering activities are allbeing performed concurrently. The challenge is tomanage the concurrency and be able to assess thestatus of the project.2.12. An SQL, a spreadsheet, a CASE code generator,graphical tools like VisualBasic, Powerbuilder, Webpage construction tools2.13. The product is more important! That’s whatpeople use and what provides benefit to end users.Chapter3Project Management Concepts
CHAPTER OVERVIEW AND COMMENTSThis chapter discusses project management at a fairly generallevel. The important point to get across is that all softwareengineers are responsible for managing some portion of theprojects they work on. Modern software development is a verycomplex undertaking that involves many people working overlong periods of time. The key to successful project managementis to focus on the four P's (people, product, process, andproject). Effective communication among customers anddevelopers is essential. The process selected must beappropriate for the people and the product. The project must beplanned if the goal is to deliver high quality software, on timeand under budget.3.1The Management SpectrumThis section provides an overview of the four P's of projectmanagement. The point to emphasize is that each the P's isimportant and it is the synergy of all four working together thatyields the successful management of software products. Thisalso the time to remind students that it is customer for whomthe product is being developed. Process framework activitiesare populated with tasks, milestones, work products, andquality assurance checkpoints regardless of the project size. Toavoid project failure developers need react to warning signs andfocus their attention on practices that are associated with goodproject management.3.2PeopleCompanies that manage their people wisely prosper in the longrun. To be effective the project team must be organized in away that maximizes each person's skills and abilities. Effectivemanagers focus on problem solving and insist on high productquality. Software teams may be organized in many differentways. Two keys factors in selecting a team organizational modelare desired level of communication among its members anddifficulty level of the problems to be solved. Hierarchicallyorganized teams can develop routine software applicationswithout much communication among the team members.Teams having a more democratic style organization oftendevelop novel applications more efficiently. It is important forstudents to understand that the larger the team, the greater the
effort required to ensure effectivecoordination of team member efforts.communicationand3.3 The ProblemThe first project management activity is the determination ofsoftware scope. This is essential to ensure the productdeveloped is the product requested by the customer. It issometimes helpful to remind students that unless developersand customers agree on the scope of the project there is no wayto determine when it ends (or when they will get paid).Regardless of the process model followed, a problem must bedecomposed along functional lines into smaller, more easilymanaged subproblems.3.4The ProcessOnce a process model is chosen, it needs to be populated withthe minimum set of work tasks and work products. Avoidprocess overkill. It is important to remind students thatframework activities are applied on every project, no matterhow small. Work tasks may vary, but not the common processframework. Process decomposition can occur simultaneouslywith product decomposition as the project plan evolves.3.5The ProjectThe text lists 10 warning signs that indicate when a softwareproject is failing. Software engineers need to be on the watch forthem and take corrective action before failure occurs. Mostfailures can be avoided by doing things right the first time andavoiding the temptation to cut corners to try to shorten thedevelopment cycle. Skipping process steps often has the effectof lengthening the development time since the amount of workusually increases. Taking time to reflect on how things wentonce a project is over, is a good habit to develop in students(who should be striving to avoid repeating their past mistakeson future projects).3.6The W5HH PrincipleBoehm's W5HH principle is a simple organizing tool that canhelp both novice and experienced software engineers focus onwhat is really important to include in a project managementplan. Boehm's questions are applicable to all software projects,regardless of their size or complexity.
3.7Critical PracticesThe Airlie Council list of project integrity critical practicesprovides a good baseline for assessing
2.1 Software Engineering - A Layered Technology Software engineering encompasses a process, the management of activities, technical methods, and use of tools to develop software products. Software is engineered by applying three distinct phases (definition, development, and support). Students need to understand that maintenance involves more
Practitioner and Legal Aid WA which makes provision for the terms upon which the Practitioner will engage with Legal Aid WA and provide legal services as a member of a panel or list; restricted practitioner means a practitioner who is entitled to engage in restricted legal practice only, pursuant to s50 or s72 of the Legal Profession Act 2008 (WA);
NURSE PRACTITIONER PROGRAM PROGRESSION, READMISSION, AND GRADUATION POLICIES . Progression Requirements for Nurse Practitioner Students . 1. Students in the nurse practitioner track must maintain a minimum grade point average (GPA) of 3.0 (B). 2. A nurse practitio ner student must achieve a "B" or better (84%) in each nurse practitioner
Materials Science and Engineering, Mechanical Engineering, Production Engineering, Chemical Engineering, Textile Engineering, Nuclear Engineering, Electrical Engineering, Civil Engineering, other related Engineering discipline Energy Resources Engineering (ERE) The students’ academic background should be: Mechanical Power Engineering, Energy .
Independent Personal Pronouns Personal Pronouns in Hebrew Person, Gender, Number Singular Person, Gender, Number Plural 3ms (he, it) א ִוה 3mp (they) Sֵה ,הַָּ֫ ֵה 3fs (she, it) א O ה 3fp (they) Uֵה , הַָּ֫ ֵה 2ms (you) הָּ תַא2mp (you all) Sֶּ תַא 2fs (you) ְ תַא 2fp (you
2 2.Software Engineering Body of Knowledge The Software Engineering Body of Knowledge (SWEBOK) is an international standard ISO/IEC TR 19759:2005[1] specifying a guide to the generally accepted Software Engineering Body of Knowledge. The Guide to the Software Engineering Body of Knowledge (SWEBOK Guide) has
SITE RELIABILITY ENGINEERING PRACTITIONER The goal of Site Reliability Engineering is to create an ultra-scalable and highly reliable distributed software systems. The Principles of Site Reliability Engineering are - Operations is a Software Problem, Service Level Objectives, Toil,
Nurse Practitioner Core Certification is to provide an entry level, competency-based . Canada who have completed a US accredited nurse practitioner program in the role of a Neonatal Nurse Practitioner to provide care to acutely and critically ill neonatal . competency statements and study guide. It also provides sample exam questions to .
FPPE Policy to Confirm Practitioner Competence and Professionalism . Practitioner Health Policy . Policy on Advance Practice Professionals . 10 . FPPE Policy to Confirm Practitioner Competence and Professionalism . Practitioner Health Policy . Policy on Advance Practice Professionals . 10
