16.453 / 16.553 software engineering university of massachusetts at lowell class meeting #5...
TRANSCRIPT
16.453 / 16.55316.453 / 16.553Software EngineeringSoftware Engineering
University of Massachusetts at LowellUniversity of Massachusetts at Lowell
Class Meeting #5Class Meeting #5
Instructor: Joe RussellInstructor: Joe RussellWebsite: http://www.geocities.com/joe_programmingWebsite: http://www.geocities.com/joe_programming
16.453 / 16.553 Software Enginee16.453 / 16.553 Software Engineeringring
22
Case StudiesCase Studies
Structured Analysis and Structured Analysis and Structured DesignStructured Design
16.453 / 16.553 Software Enginee16.453 / 16.553 Software Engineeringring
33
TopicsTopics
Case Study: Automating a Law OfficeCase Study: Automating a Law Office Case Study: Incremental DeliveryCase Study: Incremental Delivery Structured Analysis / Structured DesignStructured Analysis / Structured Design
16.453 / 16.553 Software Enginee16.453 / 16.553 Software Engineeringring
44
Case StudyCase Study
Automating a Law OfficeAutomating a Law Office
16.453 / 16.553 Software Enginee16.453 / 16.553 Software Engineeringring
55
Case Study: Case Study: Automating a Law OfficeAutomating a Law Office
Leaders of a SW Company realized that law Leaders of a SW Company realized that law offices such as title companies were poorly offices such as title companies were poorly automatedautomated
They felt a need for an integrated office They felt a need for an integrated office automation tool could lead to more efficiency in automation tool could lead to more efficiency in the law officethe law office Standard headers in documentsStandard headers in documents Pull relevant data out of a database Pull relevant data out of a database Calculate fields within a documentCalculate fields within a document Etc…Etc…
16.453 / 16.553 Software Enginee16.453 / 16.553 Software Engineeringring
66
Case Study: Case Study: Automating a Law OfficeAutomating a Law Office
Market AnalysisMarket Analysis Contacted personal acquaintances in the field Contacted personal acquaintances in the field
to determine whether they would be interested to determine whether they would be interested in the product.in the product.
Contacted members of a professional Contacted members of a professional committee to see whether there was interest committee to see whether there was interest in the productin the product
Asked for feedback as to which features Asked for feedback as to which features would be most desireablewould be most desireable
16.453 / 16.553 Software Enginee16.453 / 16.553 Software Engineeringring
77
Case Study: Case Study: Automating a Law OfficeAutomating a Law Office
Market Analysis (cont’d)Market Analysis (cont’d) Although the SW Company’s behavior seems Although the SW Company’s behavior seems
natural, there are problems with the analysisnatural, there are problems with the analysis• Sample of potential customers selected was Sample of potential customers selected was
biased. It did not represent a scientific sampling of biased. It did not represent a scientific sampling of the market.the market.
• Market analysis was performed by “pure software Market analysis was performed by “pure software engineers” who had little background in the engineers” who had little background in the marketing fieldmarketing field
16.453 / 16.553 Software Enginee16.453 / 16.553 Software Engineeringring
88
Case Study: Case Study: Automating a Law OfficeAutomating a Law Office
Economic and Financial PlanningEconomic and Financial Planning Requires the ability to forecast future sales Requires the ability to forecast future sales
and the ability to estimate costsand the ability to estimate costs• Influenced by one’s knowledge of both the price at Influenced by one’s knowledge of both the price at
which the product can be sold and the number of which the product can be sold and the number of items solditems sold
It was difficult for the SW Company to perform It was difficult for the SW Company to perform this analysis because it was driven by SW this analysis because it was driven by SW engineers who were technically savvy but not engineers who were technically savvy but not economically and financially competenteconomically and financially competent
16.453 / 16.553 Software Enginee16.453 / 16.553 Software Engineeringring
99
Case Study: Case Study: Automating a Law OfficeAutomating a Law Office
Economic and Financial Planning (cont’d)Economic and Financial Planning (cont’d) Difficulty in estimating cost is that SW doesn’t Difficulty in estimating cost is that SW doesn’t
necessarily get produced faster simply by adding necessarily get produced faster simply by adding more people to the projectmore people to the project
No risk analysis was performedNo risk analysis was performed No precautions were taken to control any known No precautions were taken to control any known
critical activitiescritical activities When it was apparent that the estimates were flawed, When it was apparent that the estimates were flawed,
nobody proposed a plan to correctnobody 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-The lesson? Short-term decisions overwhelm long-term planning … this is a very common management term planning … this is a very common management mistake!mistake!
16.453 / 16.553 Software Enginee16.453 / 16.553 Software Engineeringring
1010
Case Study: Case Study: Automating a Law OfficeAutomating a Law Office
Technical Planning and ManagementTechnical Planning and Management No analysis was performed to determine whether all No analysis was performed to determine whether all
of the product’s features were neededof the product’s features were needed Anticipation of change principle was not considered in Anticipation of change principle was not considered in
the designthe design Strong pressure was applied to have code running as Strong pressure was applied to have code running as
early as possibleearly as possible No precautions taken to minimize damages due to No precautions taken to minimize damages due to
personnel turnoverpersonnel turnover
16.453 / 16.553 Software Enginee16.453 / 16.553 Software Engineeringring
1111
Case Study: Case Study: Automating a Law OfficeAutomating a Law Office
Technical Planning and Management Technical Planning and Management Designers were attracted by the most interesting Designers were attracted by the most interesting
features of the new productfeatures of the new product Sophisticated features for the automatic computation Sophisticated features for the automatic computation
of invoices were designed, but no attention was paid of invoices were designed, but no attention was paid to standard office operations, e.g., filing large number to standard office operations, e.g., filing large number of documents.of documents.
Supposedly the employees in the company knew they Supposedly the employees in the company knew they were making these classical SE mistakes, but were making these classical SE mistakes, but nonetheless the mistakes were made.nonetheless the mistakes were made.
16.453 / 16.553 Software Enginee16.453 / 16.553 Software Engineeringring
1212
Case Study: Case Study: Automating a Law OfficeAutomating a Law Office
Project MonitoringProject Monitoring After six months, some technical and After six months, some technical and
management mistakes became apparentmanagement 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 Getting in touch with more potential users showed
that not all the features were needed … since the that not all the features were needed … since the architecture was not modular, this posed problemsarchitecture was not modular, this posed problems
16.453 / 16.553 Software Enginee16.453 / 16.553 Software Engineeringring
1313
Case Study: Case Study: Automating a Law OfficeAutomating a Law Office
• Project Monitoring (cont’d)Project Monitoring (cont’d)• How did the SW Company attempt to fix these How did the SW Company attempt to fix these
project problems?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 No systematic error and correction logs were kept
in order to save timein order to save time• Communication among designers occurred almost Communication among designers occurred almost
exclusively orally in an attempt to save timeexclusively orally in an attempt to save time
16.453 / 16.553 Software Enginee16.453 / 16.553 Software Engineeringring
1414
Case Study: Case Study: Automating a Law OfficeAutomating a Law Office
• Project Monitoring (cont’d)Project Monitoring (cont’d)• Manager’s Attitude? Since “we are almost Manager’s Attitude? Since “we are almost
done,” “we just need a little more financing done,” “we just need a little more financing and can accept almost any terms.”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 A critical and careful analysis of the mistakes that
were done in the projectwere done in the project• A replanning and/or redesign of the project as a A replanning and/or redesign of the project as a
wholewhole
16.453 / 16.553 Software Enginee16.453 / 16.553 Software Engineeringring
1515
Case Study: Case Study: Automating a Law OfficeAutomating a Law Office
Initial DeliveryInitial Delivery It was decided that income could be generated by It was decided that income could be generated by
delivering “first versions” of the product or as soon as delivering “first versions” of the product or as soon as new contracts could be signednew contracts could be signed
• In return, the customer might be a good reference resulting in In return, the customer might be a good reference resulting in increased salesincreased sales
This backfired because many of the early customers This backfired because many of the early customers had problems with the product since the product was had problems with the product since the product was never clearly definednever clearly defined
• This caused internal problems because it was not clear This caused internal problems because it was not clear whether the activity fell under product development or user whether the activity fell under product development or user assistanceassistance
16.453 / 16.553 Software Enginee16.453 / 16.553 Software Engineeringring
1616
Case Study: Case Study: Automating a Law OfficeAutomating a Law Office
Partial RecoveryPartial Recovery Eventually it was realized the managing of the Eventually it was realized the managing of the
project was leading to disaster. Steps were project was leading to disaster. Steps were made to prevent disaster:made to prevent disaster:• Responsibilities were clearly defined as to who Responsibilities were clearly defined as to who
was responsible for whatwas responsible for what• Effort made to achieve a clear picture of the state Effort made to achieve a clear picture of the state
of the product and what was required to fix itof the product and what was required to fix it The above was done at the expense of The above was done at the expense of
slowing down the project, increasing costs, slowing down the project, increasing costs, and reducing salesand reducing sales
16.453 / 16.553 Software Enginee16.453 / 16.553 Software Engineeringring
1717
Case Study: Case Study: Automating a Law OfficeAutomating a Law Office
Partial Recovery (cont’d)Partial Recovery (cont’d)How did things go?How did things go?
• People had to resist an initial feeling that the People had to resist an initial feeling that the restructuring of the project was impeding “real” progress.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 Eventually, the company produced a product with full documentationdocumentation
• The company shipped the product and earned money The company shipped the product and earned money although it was far less than initially expected due to the although it was far less than initially expected due to the delay of the introduction of the productdelay of the introduction of the product
16.453 / 16.553 Software Enginee16.453 / 16.553 Software Engineeringring
1818
Case Study: Case Study: Automating a Law OfficeAutomating a Law Office
Lessons LearnedLessons Learned Good intuition and technical skills are not Good intuition and technical skills are not
enough to guarantee successenough to guarantee success Marketing analysis and process organization Marketing analysis and process organization
must be planned carefully before committing must be planned carefully before committing to the projectto the project
Changes in schedules and project sourcing Changes in schedules and project sourcing after serious problems are encountered can after serious problems are encountered can be difficult and expensive, if not impossible to be difficult and expensive, if not impossible to implementimplement
16.453 / 16.553 Software Enginee16.453 / 16.553 Software Engineeringring
1919
Case StudyCase Study
Incremental DeliveryIncremental Delivery
16.453 / 16.553 Software Enginee16.453 / 16.553 Software Engineeringring
2020
Case Study: Case Study: Incremental DeliveryIncremental Delivery
A computer manufacturer was building a A computer manufacturer was building a new computernew computer HWENG working on HW D&DHWENG working on HW D&D SWENG working on SW D&DSWENG working on SW D&D
• The company decided to use Pascal for all its The company decided to use Pascal for all its software developmentsoftware development
• The company was going to need to develop a The company was going to need to develop a Pascal compiler with extensions to overcome Pascal compiler with extensions to overcome weaknesses of existing Pascal compilersweaknesses of existing Pascal compilers
16.453 / 16.553 Software Enginee16.453 / 16.553 Software Engineeringring
2121
Case Study: Case Study: Incremental DeliveryIncremental Delivery
The company’s language group took a poll The company’s language group took a poll of the software engineers to see what of the software engineers to see what extensions would be needed.extensions would be needed. The Result? Every language feature ever The Result? Every language feature ever
discovered was proposed by at least one discovered was proposed by at least one person as absolutely necessary for the person as absolutely necessary for the product!product!
16.453 / 16.553 Software Enginee16.453 / 16.553 Software Engineeringring
2222
Case Study: Case Study: Incremental DeliveryIncremental Delivery
The poll results made it clear that the The poll results made it clear that the compiler, with all extensions, could not be compiler, with all extensions, could not be delivered by the time other groups were delivered by the time other groups were ready to start coding.ready to start coding.
16.453 / 16.553 Software Enginee16.453 / 16.553 Software Engineeringring
2323
Case Study: Case Study: Incremental DeliveryIncremental Delivery
The language group decided to use the The language group decided to use the principle of incrementalityprinciple of incrementality The group ranked the needed extensionsThe group ranked the needed extensions The group scheduled three releases of the The group scheduled three releases of the
compiler: standard Pascal, Pascal with compiler: standard Pascal, Pascal with minimal extensions, Pascal with all other minimal extensions, Pascal with all other extensionsextensions
16.453 / 16.553 Software Enginee16.453 / 16.553 Software Engineeringring
2424
Case Study: Case Study: Incremental DeliveryIncremental Delivery
ExtensionsExtensions The extensions were first prototyped by The extensions were first prototyped by
implementing a preprocessor for an existing implementing a preprocessor for an existing Pascal compilerPascal compiler• Was slow and inefficient, but allowed the Was slow and inefficient, but allowed the
engineers to use the extensions and provide engineers to use the extensions and provide feedback to the language group as to the usability feedback to the language group as to the usability of the extensionsof the extensions
16.453 / 16.553 Software Enginee16.453 / 16.553 Software Engineeringring
2525
Case Study: Case Study: Incremental DeliveryIncremental Delivery
Hardware ArrivesHardware Arrives By this time, a Pascal compiler with minimal By this time, a Pascal compiler with minimal
extensions is availableextensions is available• Allowed engineers to start implementing their Allowed engineers to start implementing their
software (OS & database) using the compilersoftware (OS & database) using the compiler• Many people had earlier versions of their software Many people had earlier versions of their software
already developed and tested from the prototype already developed and tested from the prototype compiler … a simple recompile was all that was compiler … a simple recompile was all that was necessarynecessary
16.453 / 16.553 Software Enginee16.453 / 16.553 Software Engineeringring
2626
Case Study: Case Study: Incremental DeliveryIncremental Delivery
After Six Months …After Six Months … The language group took another poll of the The language group took another poll of the
software engineers and found that NO other software engineers and found that NO other extensions were needed!extensions were needed!
However, since the original list didn’t include However, since the original list didn’t include efficiency-related extensions, a new extension efficiency-related extensions, a new extension was added to aid in the efficiency (logical was added to aid in the efficiency (logical operations on integers)operations on integers)
16.453 / 16.553 Software Enginee16.453 / 16.553 Software Engineeringring
2727
Case Study: Case Study: Incremental DeliveryIncremental Delivery
Over Time …Over Time … Several other compiler releases occurredSeveral 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 Incremental Delivery allowed users to have access to useful functionality and have access to useful functionality and allowed the compiler developers to allowed the compiler developers to enhance the compiler on the basis of enhance the compiler on the basis of explicit and definitive user feedback!explicit and definitive user feedback!
16.453 / 16.553 Software Enginee16.453 / 16.553 Software Engineeringring
2828
Case Study: Case Study: Incremental DeliveryIncremental Delivery
Lessons LearnedLessons Learned Prototyping is possiblePrototyping is possible A throw-away prototype may be used by A throw-away prototype may be used by
clients to start on their project while they await clients to start on their project while they await the final productthe final product
A throw-away prototype enables parallel A throw-away prototype enables parallel development by clients and developersdevelopment by clients and developers
A throw-away prototype may be used to prune A throw-away prototype may be used to prune an initial set of requirements on the basis of an initial set of requirements on the basis of actual usage and need for features.actual usage and need for features.
16.453 / 16.553 Software Enginee16.453 / 16.553 Software Engineeringring
2929
Organizing The Software ProcessOrganizing The Software Process
Organizing the software process is a Organizing the software process is a critical activity involving everything from critical activity involving everything from the management of people to the the management of people to the management of all productsmanagement of all products Involves definition of appropriate methods and Involves definition of appropriate methods and
their combination within methodologiestheir combination within methodologies
16.453 / 16.553 Software Enginee16.453 / 16.553 Software Engineeringring
3030
Methods and MethodologiesMethods and Methodologies
According to Webster’s New World According to Webster’s New World Dictionary (1977):Dictionary (1977): Method – A way of doing anything, especially Method – A way of doing anything, especially
in an orderly wayin an orderly way Methodology – A system of methodsMethodology – A system of methods
16.453 / 16.553 Software Enginee16.453 / 16.553 Software Engineeringring
3131
Appeal of MethodologiesAppeal of Methodologies
Methodologies that guide programmers in Methodologies that guide programmers in their work in all phases of development:their work in all phases of development: Increase people’s confidence in what they are Increase people’s confidence in what they are
doingdoing Teaches inexperience people how to solve Teaches inexperience people how to solve
problems in a systematic wayproblems in a systematic way Encourages a uniform, standard approach to Encourages a uniform, standard approach to
problem solvingproblem solving
16.453 / 16.553 Software Enginee16.453 / 16.553 Software Engineeringring
3232
Structured Analysis / Structured Analysis / Structured Design (SA/SD)Structured Design (SA/SD)
In Requirements an Analysis phase, SA/SD In Requirements an Analysis phase, SA/SD suggests three major conceptual tools for suggests three major conceptual tools for constructing system modelsconstructing 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 SA/SD is Function-Oriented and its modules represent functional abstractionsrepresent functional abstractions
16.453 / 16.553 Software Enginee16.453 / 16.553 Software Engineeringring
3333
Data Flow DiagramData Flow Diagram
Used for specifying the functional requirements Used for specifying the functional requirements of the systemof the system Function represented by bubblesFunction represented by bubbles Data flows represented by arrowsData flows represented by arrows
• direction is with respect to the range of the function direction is with respect to the range of the function represented by the bubblerepresented by the bubble
Data stores are represented by open boxesData 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 boxesInput/Output represented by special I/O boxes• Describe data acquisition and generation during human-Describe data acquisition and generation during human-
computer interactioncomputer interaction
16.453 / 16.553 Software Enginee16.453 / 16.553 Software Engineeringring
3434
Data Flow DiagramData Flow Diagram
A file
Adata
transformer
An output deviceAn input
device
16.453 / 16.553 Software Enginee16.453 / 16.553 Software Engineeringring
3535
Employee_1
Registration
Employee_2
Authorization
Employee_3
Response
Request
Request
Result
Authorized_requests
Employee_4Employee_6
Employee_5
Process ProcessProcess
Order_request
Complete_order
Analysis ofoffice work
16.453 / 16.553 Software Enginee16.453 / 16.553 Software Engineeringring
3636
Extract order data
Get letter form
Order request
Letter form
Letter forms
Quantity to order
Type of letter
Compose order
Get address
Addresses
Address
Addressee
AddressComplete order
Authorized requests
AutomatedPortion of Office Work
16.453 / 16.553 Software Enginee16.453 / 16.553 Software Engineeringring
3737
From Analysis and From Analysis and Requirements to DesignRequirements to Design
The preceding DFDs specify the functional The preceding DFDs specify the functional requirements of the office workrequirements of the office work
The “Design”, i.e., the decomposition of The “Design”, i.e., the decomposition of the system into modules, is based directly the system into modules, is based directly on the DFDs and is documented using on the DFDs and is documented using Structured Diagrams (SDs)Structured Diagrams (SDs)
16.453 / 16.553 Software Enginee16.453 / 16.553 Software Engineeringring
3838
Structured DiagramsStructured Diagrams
A Structured Diagram is a Directed Acyclic A Structured Diagram is a Directed Acyclic Graph (DAG)-like structureGraph (DAG)-like structure Nodes represent modulesNodes represent modules Each module represents a functional abstraction to be Each module represents a functional abstraction to be
implemented later by a subprogramimplemented later by a subprogram
The method to transform DFDs into SDs should The method to transform DFDs into SDs should aim to:aim to: minimize couplingminimize coupling maximize cohesionmaximize cohesion
16.453 / 16.553 Software Enginee16.453 / 16.553 Software Engineeringring
3939
Structured DiagramsStructured Diagrams
SDs may be decorated with additional SDs may be decorated with additional notationsnotations Show parameter flow between modules by Show parameter flow between modules by
arrow and parameter namearrow and parameter name Show control patterns governing the calls of Show control patterns governing the calls of
subordinate modulessubordinate modules• Diamond represents selection between modules to Diamond represents selection between modules to
callcall• Curved arrow represents loops of calls to a moduleCurved arrow represents loops of calls to a module
16.453 / 16.553 Software Enginee16.453 / 16.553 Software Engineeringring
4040
Structured DiagramsStructured Diagrams A Directed Acyclic Graph of functional modules
Direction of arrow is implicitly downward
M
MMM 1 32
16.453 / 16.553 Software Enginee16.453 / 16.553 Software Engineeringring
4141
Decorated Structured DiagramDecorated Structured DiagramM
MMM 1 32
M 1,1 M 1,2
XX Y
Y
X XX
11
M1 abstract inputM2 transformationM3 abstract output
16.453 / 16.553 Software Enginee16.453 / 16.553 Software Engineeringring
4242
Decorated Structured DiagramDecorated Structured Diagram
Order main
Get data
Produce data for order form
Print order form
T
Q
AE
AE
T
A
L
A
L
Q
SD for the “Automated Portion" DFDSD for the “Automated Portion" DFD
LEGENDLEGENDT = Type of LetterT = Type of LetterQ = QuantityQ = QuantityAE = AddresseeAE = AddresseeL = Letter FormL = Letter FormA = AddressA = Address