Dare: “inthe absence of meaning stoners, 0m lady ke sofware comes fo depend insted on foe Tom Deltorco COMAPTED | SOFTWALE AUD SOFTIMAGE EGINEEDING - The sixth Princlple: Plan Ahead for Reuse Neuse saves time and effort. Achleving a high level of reuse is arguably the hardest goal 1 accomplish in developing a software system. The reuse of code and design has been proclaimed as a major benefit of using object-oriented technolo- gles. However, the return on this investment Is not automatic, To leverage the reuse possiblities that object-oriented {or conventional) programming provides requires forethought and planning, There are many techniques to realize reuse at every level of the system development process... . Planning ahead for reuse reduces the cost and increases the value of both the reusable components and the systems into which they are incorporated. ‘The Seventh principle: Think? This last principle is probably the most overlooked, Placing clear, complete thought before action almost always produces better results, When you think about something, you are morc likely to do it right. You also gain knowledge about how to do it right again, Ifyou do think about something and still do it wrong, It be- comes a valuable experience, A side effect of thinking is learning to recognize ‘when you don’t know something, at which point you can research the answer. ‘When clear thought has gone into a system, value comes out. Applying the first six principles requires intense thought, for which the potential rewards are enormous Aware team simply followed Hooker's seven If every software engineer and every sof -omputer- principles, many of the difficulties we experience in building complex c based systems would be eliminated. lefs about software and the process that is used to oti itaean be traced tothe earliest days of computing, Myths have a number of uirlbutes that make them Insidious, For Instance, they appear to be reasonable aeMtements of fact (sometimes containing elements of ruth), they have an intuitive feel and they are often promulgated by experienced practitioners who “know the Software myths—erroneous beli score." ‘Today, most knowledgeable sofware en} for what they are—misleading attitudes t managers and practitioners alike. However, modify, and remnants of software myths rematn. gineering professionals recognize myths that have caused serious problems for old attitudes and habits are difficult to who reuse the software on future projects, reuse cn be expensive id bold reusable components. Stodles indicate that designing and “cost between 25 1 20 percent more than targeted software, In 16 Although tis fs true for those for those who must design an pulling reusable components can tome eases, the cost diferential cannot be justiity, ke managers In anngement myths, Managers wit satware TesponsPily resins fe nae rennin o main bus key ees rm Siping and imp uty ie downing person who prays at asta, 0 eee geaansarencn grape at beletina software mth, i that belie wil essen pressure (even temporarily) Myth: We already have a book that’s ful of standards and procedures for building software, Won't that provide my people with everything they need o know? ‘The book of standards may very well exist, but is it used? Are soft- ware practitioners aware of ts existence? Does I reflect modern software engineering practice? ts it complete? Is it adaptable? Is it streamlined to improve time-to-delivery while stil maintaining a {ocus on quality? In many cases, the answer to all ofthese questions is "no. we get behind schedule, we can add more programmers and catch up (sometimes called the ‘Mongolian horde” concept) Software development is not a mechanistle process like manufactur- ‘ng. in the words of Brooks {Bro95): “adding people to a late soft- ware project makes it later.” At first, this statement may seem counterintuitive. However, as new people are added, people who were working must spend time educating the newcomers, thereby reducing the amount of time spent on productive development effort. People can be added but only in a planned and well- coordinated manner. If decide to outsource the software project o a third paryy, I can just rele and let that firm bt {fan organization does not understand how to manage and control software projects internally it will invariably struggle when it out- sources software projects. Customer myths, A customer who requests computer software may be a person at the next desk, 2 technical group down the hall, the marketing/sales department, oF an outside company that has requested software under contract. In many cases, the customer believes myths about software because software mangers and prac. tttioners do litle to correct misinformaticn. Myths lead to false expectations (by the customer) and, ultimately, dissatisfaction with the developer. Myth: A general statement of objectives is suficient to begin writing Programs—we can fil in the detalls later. Reality: Although a comprehensive and stable statement of fequirements is ‘ot always possible, an ambiguous “statement of objectives" is a recipe for disaster. Unambiguous requirements (usually derived Myth: Reality: Myth: Reality:sorrwage mncnttan, ce iteratively) are developed only through effective and continuous Communication between customer and developer. Myth: Software requircments continually change, but change can be casily ‘accommodated because software is fleuble. Reality: ts trie that software requirements change, but the impact of ‘change varies with the time at which itis introduced. When require- ments changes are requested early (before design or code has been started), the cost impact is relatively smal.!® However, as time passes, the cost impact grows rapidly—resources have been commnit- ted, a design framework has been established, and change can cause upheaval that requires additional resources and major design modification. GonaH Practitioner's myths. Myths that are stil believed by software practitioners have been fostered by over 50 years of programming culture. During the eatly days, Pro- tower, gaming was viewed as an a form Olé way and ates de ar regattosiee't sayen: Once te we the program and gtitto work. our job is done cckyorsl, “Wilwe Realit ‘Someone once said that “the sooner you begin ‘writing code,’ the lorgsbéton Teer ake you to get done: nda data nate tat een G0 and 20 percent of all effort expended on software wil be ex- pended after itis delivered tothe customer forthe first time. tnd get the program Tanning" have nowy of assessing i qual One ofthe most effective software quality assurance mechanisms an be applies from the inception ofa projet—the technica evew Sofware reviews (Jserbed in Chapter 16) are a “quality ter” that have been found wo be more eflective than testing fr finding certain classes of sofware defects. Myth: The oly deverable work productfora succesful projects the working program. Reality: A working program is only one part ofa sotware configuration that Includes many elements. A variety of work products (eg. models, documents, plans provide a foundation for successful engineering and, more Important, guidance for sotware suppor. Myth: Software enginering ill make us create voluminous and unnecessary documentation and will mvariaby slow us down. Software engineering isnot about creating documents. is about creating a quay product. Better qual leads to reduced rework, and reduced rework result in faster delivery times 1é Many sofware engineers have adopted an “agile” approach that accommodates change incre- mentally, thereby controling its Impact and cost. Agile methods are discussed in Chapter 3I 24 SOFTWARE AND SOFTWARE ENGINEERING CHAPTER 1 Many software professionals recognize the fallacy of the myths just described. Regrettably, habitual attitudes and methods foster poor management and technical practices, even when reality dictates a better approach. Recognition of software : realities is the first step toward formulation of practical solutions for software engineering. Every software project is precipitated by some business need—the need to correct a defect in an existing application; the need to adapt a “legacy system’ to a changing business environment; the need to extend the functions and features of an existing application; or the need to create a new product, service, or system. At the beginning of a software project, the business need is often expressed informally as part of a simple conversation, The conversation presented in the sidebar is typical. Rao ities ‘The scene: Meeting room at CPI Corporation, 0 {fcional] company that makes consumer products for home and commercial use. How a Project Starts ‘The players: Mol Golden, senior manager, product development; Lisa Perez, marketing monoger; Lee Warren, engineering manoger; Joe Comalleri, executive ‘VP, business development The conversation: Joe: Okcy, Lee, whats his | hear about your folks developing @ whol? A generic universal wireless box? Lee: I's prety cool... obout he size ofa src matchbook .. . we can attach ito sensors of ll kinds, digital comero, jst bout anything. Using the 202.11 \viveless protocol. It allows us fo access the device's ouput thou! wires. We think if lead to @ whole new generation of products Joes You agree, Mal? ‘Mal: | do. In fot, wth soles os lat os they ve been this yeor, we need somelhing new. Lisa and | have been ‘Toing a ile market research, and we think we've goto line of products thot could be big. 17 The Safetfome project will be used thr Joe: How big . . . bottom line big? Mol (avoiding a direct commitment): Tell him bout our idea, lisa, Lisa Ifs o whole new generation of what we coll “home management products.” We call em Safetome, They use the new wireless interfoce, provide homeowners or smoll- ‘business people with o system thot controlled by their: PC—home security, home surveillance, appliance ond device control—you know, tun down the home oir conditioner while you're driving home, that sort of hing Lee {jumping in): Engineering's done a technical feasibiliy study ofthis idea, Joe. vs docble ot low manufacturing cost, Most hardwore is oft-the shel. Softwore is cn issue, bu it’ nothing that we cant do. Joe: Interesting. Now, l asked about the bottom line. Mal: PCs have penetrated over 70 percent of ll households in the USA. I we could price this hing right, it could be o killer-App. Nobody else has our wireless box... is proprietary. Well have a 2-year jump on the compeliion, Revenue? Maybe os much as 30 to 40 milion dollors inthe second yeor. ing]: Lets tke this tothe next level. rm ccughout this book toillustrate the inner workings ofa project team as it builds a software product. The company the project, andthe People are purely fictitious, put the situations and problems are real.