1. 16.453 / 16.553 Software Engineering University of Massachusetts at Lowell Class Meeting #5 Instructor: Joe Russell Website: http://www.geocities.com/joe_programming

2. 16.453 / 16.553 Software Engineering2 Case Studies Structured Analysis and Structured Design

3. 16.453 / 16.553 Software Engineering3 Topics  Case Study: Automating a Law Office  Case Study: Incremental Delivery  Structured Analysis / Structured Design

4. 16.453 / 16.553 Software Engineering4 Case Study Automating a Law Office

5. 16.453 / 16.553 Software Engineering5 Case Study: Automating a Law Office  Leaders of a SW Company realized that law offices such as title companies were poorly automated  They felt a need for an integrated office automation tool could lead to more efficiency in the law office Standard headers in documents Standard headers in documents Pull relevant data out of a database Pull relevant data out of a database Calculate fields within a document Calculate fields within a document Etc… Etc…

6. 16.453 / 16.553 Software Engineering6 Case Study: Automating a Law Office  Market Analysis Contacted personal acquaintances in the field to determine whether they would be interested in the product. Contacted personal acquaintances in the field to determine whether they would be interested in the product. Contacted members of a professional committee to see whether there was interest in the product Contacted members of a professional committee to see whether there was interest in the product Asked for feedback as to which features would be most desireable Asked for feedback as to which features would be most desireable

7. 16.453 / 16.553 Software Engineering7 Case Study: Automating a Law Office  Market Analysis (cont ’ d) Although the SW Company ’ s behavior seems natural, there are problems with the analysis Although the SW Company ’ s behavior seems natural, there are problems with the analysis Sample of potential customers selected was biased. It did not represent a scientific sampling of the market.Sample of potential customers selected was biased. It did not represent a scientific sampling of the market. Market analysis was performed by “ pure software engineers ” who had little background in the marketing fieldMarket analysis was performed by “ pure software engineers ” who had little background in the marketing field

8. 16.453 / 16.553 Software Engineering8 Case Study: Automating a Law Office  Economic and Financial Planning Requires the ability to forecast future sales and the ability to estimate costs Requires the ability to forecast future sales and the ability to estimate costs Influenced by one’s knowledge of both the price at which the product can be sold and the number of items soldInfluenced by one’s knowledge of both the price at which the product can be sold and the number of items sold It was difficult for the SW Company to perform this analysis because it was driven by SW engineers who were technically savvy but not economically and financially competent It was difficult for the SW Company to perform this analysis because it was driven by SW engineers who were technically savvy but not economically and financially competent

9. 16.453 / 16.553 Software Engineering9 Case Study: Automating a Law Office  Economic and Financial Planning (cont’d) Difficulty in estimating cost is that SW doesn’t necessarily get produced faster simply by adding more people to the project Difficulty in estimating cost is that SW doesn’t necessarily get produced faster simply by adding more people to the project No risk analysis was performed No risk analysis was performed No precautions were taken to control any known critical activities No precautions were taken to control any known critical activities When it was apparent that the estimates were flawed, nobody proposed a plan to correct When it was apparent that the estimates were flawed, nobody proposed a plan to correct Only day-by-day actions were undertakenOnly day-by-day actions were undertaken The lesson? Short-term decisions overwhelm long- term planning … this is a very common management mistake! The lesson? Short-term decisions overwhelm long- term planning … this is a very common management mistake!

10. 16.453 / 16.553 Software Engineering10 Case Study: Automating a Law Office  Technical Planning and Management No analysis was performed to determine whether all of the product’s features were needed No analysis was performed to determine whether all of the product’s features were needed Anticipation of change principle was not considered in the design Anticipation of change principle was not considered in the design Strong pressure was applied to have code running as early as possible Strong pressure was applied to have code running as early as possible No precautions taken to minimize damages due to personnel turnover No precautions taken to minimize damages due to personnel turnover

11. 16.453 / 16.553 Software Engineering11 Case Study: Automating a Law Office  Technical Planning and Management Designers were attracted by the most interesting features of the new product Designers were attracted by the most interesting features of the new product Sophisticated features for the automatic computation of invoices were designed, but no attention was paid to standard office operations, e.g., filing large number of documents. Sophisticated features for the automatic computation of invoices were designed, but no attention was paid to standard office operations, e.g., filing large number of documents. Supposedly the employees in the company knew they were making these classical SE mistakes, but nonetheless the mistakes were made. Supposedly the employees in the company knew they were making these classical SE mistakes, but nonetheless the mistakes were made.

12. 16.453 / 16.553 Software Engineering12 Case Study: Automating a Law Office  Project Monitoring After six months, some technical and management mistakes became apparent After six months, some technical and management mistakes became apparent Lack of clear definition of product’s functionalityLack of clear definition of product’s functionality Some important features had been neglectedSome important features had been neglected Getting in touch with more potential users showed that not all the features were needed … since the architecture was not modular, this posed problemsGetting in touch with more potential users showed that not all the features were needed … since the architecture was not modular, this posed problems

13. 16.453 / 16.553 Software Engineering13 Case Study: Automating a Law Office Project Monitoring (cont’d)Project Monitoring (cont’d) How did the SW Company attempt to fix these project problems?How did the SW Company attempt to fix these project problems? More effort put forth to try to fix the problemsMore effort put forth to try to fix the problems SW patches were made wildlySW patches were made wildly No systematic error and correction logs were kept in order to save timeNo systematic error and correction logs were kept in order to save time Communication among designers occurred almost exclusively orally in an attempt to save timeCommunication among designers occurred almost exclusively orally in an attempt to save time

14. 16.453 / 16.553 Software Engineering14 Case Study: Automating a Law Office Project Monitoring (cont’d)Project Monitoring (cont’d) Manager’s Attitude? Since “we are almost done,” “we just need a little more financing and can accept almost any terms.”Manager’s Attitude? Since “we are almost done,” “we just need a little more financing and can accept almost any terms.” What could have been done?What could have been done? A critical and careful analysis of the mistakes that were done in the projectA critical and careful analysis of the mistakes that were done in the project A replanning and/or redesign of the project as a wholeA replanning and/or redesign of the project as a whole

15. 16.453 / 16.553 Software Engineering15 Case Study: Automating a Law Office  Initial Delivery It was decided that income could be generated by delivering “first versions” of the product or as soon as new contracts could be signed It was decided that income could be generated by delivering “first versions” of the product or as soon as new contracts could be signed In return, the customer might be a good reference resulting in increased salesIn return, the customer might be a good reference resulting in increased sales This backfired because many of the early customers had problems with the product since the product was never clearly defined This backfired because many of the early customers had problems with the product since the product was never clearly defined This caused internal problems because it was not clear whether the activity fell under product development or user assistanceThis caused internal problems because it was not clear whether the activity fell under product development or user assistance

16. 16.453 / 16.553 Software Engineering16 Case Study: Automating a Law Office  Partial Recovery Eventually it was realized the managing of the project was leading to disaster. Steps were made to prevent disaster: Eventually it was realized the managing of the project was leading to disaster. Steps were made to prevent disaster: Responsibilities were clearly defined as to who was responsible for whatResponsibilities were clearly defined as to who was responsible for what Effort made to achieve a clear picture of the state of the product and what was required to fix itEffort made to achieve a clear picture of the state of the product and what was required to fix it The above was done at the expense of slowing down the project, increasing costs, and reducing sales The above was done at the expense of slowing down the project, increasing costs, and reducing sales

17. 16.453 / 16.553 Software Engineering17 Case Study: Automating a Law Office  Partial Recovery (cont’d) How did things go? How did things go? People had to resist an initial feeling that the restructuring of the project was impeding “real” progress.People had to resist an initial feeling that the restructuring of the project was impeding “real” progress. Over time, improvements became apparentOver time, improvements became apparent Eventually, the company produced a product with full documentationEventually, the company produced a product with full documentation The company shipped the product and earned money although it was far less than initially expected due to the delay of the introduction of the productThe company shipped the product and earned money although it was far less than initially expected due to the delay of the introduction of the product

18. 16.453 / 16.553 Software Engineering18 Case Study: Automating a Law Office  Lessons Learned Good intuition and technical skills are not enough to guarantee success Good intuition and technical skills are not enough to guarantee success Marketing analysis and process organization must be planned carefully before committing to the project Marketing analysis and process organization must be planned carefully before committing to the project Changes in schedules and project sourcing after serious problems are encountered can be difficult and expensive, if not impossible to implement Changes in schedules and project sourcing after serious problems are encountered can be difficult and expensive, if not impossible to implement

19. 16.453 / 16.553 Software Engineering19 Case Study Incremental Delivery

20. 16.453 / 16.553 Software Engineering20 Case Study: Incremental Delivery  A computer manufacturer was building a new computer HWENG working on HW D&D HWENG working on HW D&D SWENG working on SW D&D SWENG working on SW D&D The company decided to use Pascal for all its software developmentThe company decided to use Pascal for all its software development The company was going to need to develop a Pascal compiler with extensions to overcome weaknesses of existing Pascal compilersThe company was going to need to develop a Pascal compiler with extensions to overcome weaknesses of existing Pascal compilers

21. 16.453 / 16.553 Software Engineering21 Case Study: Incremental Delivery  The company’s language group took a poll of the software engineers to see what extensions would be needed. The Result? Every language feature ever discovered was proposed by at least one person as absolutely necessary for the product! The Result? Every language feature ever discovered was proposed by at least one person as absolutely necessary for the product!

22. 16.453 / 16.553 Software Engineering22 Case Study: Incremental Delivery  The poll results made it clear that the compiler, with all extensions, could not be delivered by the time other groups were ready to start coding.

23. 16.453 / 16.553 Software Engineering23 Case Study: Incremental Delivery  The language group decided to use the principle of incrementality The group ranked the needed extensions The group ranked the needed extensions The group scheduled three releases of the compiler: standard Pascal, Pascal with minimal extensions, Pascal with all other extensions The group scheduled three releases of the compiler: standard Pascal, Pascal with minimal extensions, Pascal with all other extensions

24. 16.453 / 16.553 Software Engineering24 Case Study: Incremental Delivery  Extensions The extensions were first prototyped by implementing a preprocessor for an existing Pascal compiler The extensions were first prototyped by implementing a preprocessor for an existing Pascal compiler Was slow and inefficient, but allowed the engineers to use the extensions and provide feedback to the language group as to the usability of the extensionsWas slow and inefficient, but allowed the engineers to use the extensions and provide feedback to the language group as to the usability of the extensions

25. 16.453 / 16.553 Software Engineering25 Case Study: Incremental Delivery  Hardware Arrives By this time, a Pascal compiler with minimal extensions is available By this time, a Pascal compiler with minimal extensions is available Allowed engineers to start implementing their software (OS & database) using the compilerAllowed engineers to start implementing their software (OS & database) using the compiler Many people had earlier versions of their software already developed and tested from the prototype compiler … a simple recompile was all that was necessaryMany people had earlier versions of their software already developed and tested from the prototype compiler … a simple recompile was all that was necessary

26. 16.453 / 16.553 Software Engineering26 Case Study: Incremental Delivery  After Six Months … The language group took another poll of the software engineers and found that NO other extensions were needed! The language group took another poll of the software engineers and found that NO other extensions were needed! However, since the original list didn’t include efficiency-related extensions, a new extension was added to aid in the efficiency (logical operations on integers) However, since the original list didn’t include efficiency-related extensions, a new extension was added to aid in the efficiency (logical operations on integers)

27. 16.453 / 16.553 Software Engineering27 Case Study: Incremental Delivery  Over Time … Several other compiler releases occurred Several other compiler releases occurred More sophisticated level of code optimizationMore sophisticated level of code optimization More extensions addedMore extensions added  Incremental Delivery allowed users to have access to useful functionality and allowed the compiler developers to enhance the compiler on the basis of explicit and definitive user feedback!

28. 16.453 / 16.553 Software Engineering28 Case Study: Incremental Delivery  Lessons Learned Prototyping is possible Prototyping is possible A throw-away prototype may be used by clients to start on their project while they await the final product A throw-away prototype may be used by clients to start on their project while they await the final product A throw-away prototype enables parallel development by clients and developers A throw-away prototype enables parallel development by clients and developers A throw-away prototype may be used to prune an initial set of requirements on the basis of actual usage and need for features. A throw-away prototype may be used to prune an initial set of requirements on the basis of actual usage and need for features.

29. 16.453 / 16.553 Software Engineering29 Organizing The Software Process  Organizing the software process is a critical activity involving everything from the management of people to the management of all products Involves definition of appropriate methods and their combination within methodologies Involves definition of appropriate methods and their combination within methodologies

30. 16.453 / 16.553 Software Engineering30 Methods and Methodologies  According to Webster’s New World Dictionary (1977): Method – A way of doing anything, especially in an orderly way Method – A way of doing anything, especially in an orderly way Methodology – A system of methods Methodology – A system of methods

31. 16.453 / 16.553 Software Engineering31 Appeal of Methodologies  Methodologies that guide programmers in their work in all phases of development: Increase people’s confidence in what they are doing Increase people’s confidence in what they are doing Teaches inexperience people how to solve problems in a systematic way Teaches inexperience people how to solve problems in a systematic way Encourages a uniform, standard approach to problem solving Encourages a uniform, standard approach to problem solving

32. 16.453 / 16.553 Software Engineering32 Structured Analysis / Structured Design (SA/SD)  In Requirements an Analysis phase, SA/SD suggests three major conceptual tools for constructing system models Data Flow Diagrams (DFDs) Data Flow Diagrams (DFDs) Used for specifying the functional requirements of the systemUsed for specifying the functional requirements of the system Data Dictionaries (DDs) Data Dictionaries (DDs) Centralized definitionsCentralized definitions Structured English (SE) Structured English (SE) To describe transformation of terminal bubblesTo describe transformation of terminal bubbles  SA/SD is Function-Oriented and its modules represent functional abstractions

33. 16.453 / 16.553 Software Engineering33 Data Flow Diagram  Used for specifying the functional requirements of the system Function represented by bubbles Function represented by bubbles Data flows represented by arrows Data flows represented by arrows direction is with respect to the range of the function represented by the bubbledirection is with respect to the range of the function represented by the bubble Data stores are represented by open boxes Data stores are represented by open boxes two horizontal lines with data store name enclosedtwo horizontal lines with data store name enclosed Input/Output represented by special I/O boxes Input/Output represented by special I/O boxes Describe data acquisition and generation during human- computer interactionDescribe data acquisition and generation during human- computer interaction

34. 16.453 / 16.553 Software Engineering34 Data Flow Diagram

35. 16.453 / 16.553 Software Engineering35 Analysis of office work

36. 16.453 / 16.553 Software Engineering36 Automated Portion of Office Work

37. 16.453 / 16.553 Software Engineering37 From Analysis and Requirements to Design  The preceding DFDs specify the functional requirements of the office work  The “Design”, i.e., the decomposition of the system into modules, is based directly on the DFDs and is documented using Structured Diagrams (SDs)

38. 16.453 / 16.553 Software Engineering38 Structured Diagrams  A Structured Diagram is a Directed Acyclic Graph (DAG)-like structure Nodes represent modules Nodes represent modules Each module represents a functional abstraction to be implemented later by a subprogram Each module represents a functional abstraction to be implemented later by a subprogram  The method to transform DFDs into SDs should aim to: minimize coupling minimize coupling maximize cohesion maximize cohesion

39. 16.453 / 16.553 Software Engineering39 Structured Diagrams  SDs may be decorated with additional notations Show parameter flow between modules by arrow and parameter name Show parameter flow between modules by arrow and parameter name Show control patterns governing the calls of subordinate modules Show control patterns governing the calls of subordinate modules Diamond represents selection between modules to callDiamond represents selection between modules to call Curved arrow represents loops of calls to a moduleCurved arrow represents loops of calls to a module

40. 16.453 / 16.553 Software Engineering40 Structured Diagrams   A Directed Acyclic Graph of functional modules Direction of arrow is implicitly downward

41. 16.453 / 16.553 Software Engineering41 Decorated Structured Diagram M 1 abstract input M 2 transformation M 3 abstract output

42. 16.453 / 16.553 Software Engineering42 Decorated Structured Diagram SD for the “Automated Portion" DFD LEGEND T = Type of Letter Q = Quantity AE = Addressee L = Letter Form A = Address