software engineering notes
TRANSCRIPT
![Page 1: software engineering notes](https://reader034.vdocuments.us/reader034/viewer/2022042700/557202464979599169a340be/html5/thumbnails/1.jpg)
Software?Instructions providing desired function and performance
Data structure that enable program to adequately manipulate information
Both a product and a vehicle for developing a product
Software is engineered not manufactured
Does not wear out but it does deteriorate
Documents describing operations and use of programs
Computer Programs Associated Documentation
1
![Page 2: software engineering notes](https://reader034.vdocuments.us/reader034/viewer/2022042700/557202464979599169a340be/html5/thumbnails/2.jpg)
Software Engineering/System Engineering
Concerned with all aspects of software production
Concerned with all aspects of computer-based systems development including
hardware, software and process engineering
System engineers are involved in system specification, architectural design, integration and deployment
Software engineeri
ng
System engineeri
ng
is part of
2
![Page 3: software engineering notes](https://reader034.vdocuments.us/reader034/viewer/2022042700/557202464979599169a340be/html5/thumbnails/3.jpg)
Software Process
set of activities whose goal is development or evolution of software
Specification - what the system should do and its development constraints
Development - production of software system
Validation - checking that the software is what the customer wants
Evolution - changing the software in response to changing demands
Generic activities in all software processes
3
![Page 4: software engineering notes](https://reader034.vdocuments.us/reader034/viewer/2022042700/557202464979599169a340be/html5/thumbnails/4.jpg)
Software Process ModelA simplified representation of a software process, presented from a specific perspective
Workflow perspective represents inputs, outputs and dependencies Data-flow perspective represents data transformation activities Role/action perspective represents the roles/activities of the people involved in software process
Generic process modelsWaterfallEvolutionary developmentFormal transformationIntegration from reusable components 4
![Page 5: software engineering notes](https://reader034.vdocuments.us/reader034/viewer/2022042700/557202464979599169a340be/html5/thumbnails/5.jpg)
Software Crisis
Software failures receive a lot more publicity than software engineering success stories
Problems that afflict software development are associated more with how to develop and support software properly than with simply building software which functions correctly
5
![Page 6: software engineering notes](https://reader034.vdocuments.us/reader034/viewer/2022042700/557202464979599169a340be/html5/thumbnails/6.jpg)
Software Failure Curve
6
![Page 7: software engineering notes](https://reader034.vdocuments.us/reader034/viewer/2022042700/557202464979599169a340be/html5/thumbnails/7.jpg)
Emergence of Software Engineering
Early Computer Programming- Exploratory Style- Evolving aspect- Use of intuition of
programmers- Use of assembly code- About 100 lines of codes
7
![Page 8: software engineering notes](https://reader034.vdocuments.us/reader034/viewer/2022042700/557202464979599169a340be/html5/thumbnails/8.jpg)
Emergence of Software Engineering
High Level Language Programming
- Larger Programs- COBOL, FORTRAN- Exploratory Style- Few 1000s Lines of Code- Unstructured programs (use of goto statement)
8
![Page 9: software engineering notes](https://reader034.vdocuments.us/reader034/viewer/2022042700/557202464979599169a340be/html5/thumbnails/9.jpg)
Emergence of Software Engineering
Control Flow Based Programming- Flow Chart Technique used
- Focus on Design of Program’s control flow structure
- Structured programming
(only use sequential, selection, iterations)
9
![Page 10: software engineering notes](https://reader034.vdocuments.us/reader034/viewer/2022042700/557202464979599169a340be/html5/thumbnails/10.jpg)
Emergence of Software Engineering
Data Structure Oriented
- Several thousands of Lines of Code- Focus given to Data Structure first
10
![Page 11: software engineering notes](https://reader034.vdocuments.us/reader034/viewer/2022042700/557202464979599169a340be/html5/thumbnails/11.jpg)
Emergence of Software Engineering
Unstructured Program Structured Program
If(bal>withdrl){ issue_money = TRUE;goto 110:} elseif (priv_cust == TRUE){ goto 100; else goto 140; activate_cash_dispenser(); print(error);
If(priv_cust||(bal>withdrl){ activate_cash_dispenser();} else print(error);
11
![Page 12: software engineering notes](https://reader034.vdocuments.us/reader034/viewer/2022042700/557202464979599169a340be/html5/thumbnails/12.jpg)
Emergence of Software Engineering
Data Flow Oriented Design- Use of Data Flow Diagrams
Represents Data Items and Functions
- Program Structure is Designed from DFD
Authenticate
Password
Welcome Msg + Username
UsernameGrant Access
Database12
![Page 13: software engineering notes](https://reader034.vdocuments.us/reader034/viewer/2022042700/557202464979599169a340be/html5/thumbnails/13.jpg)
Emergence of Software Engineering
Object Oriented Design
- Objects are identified first
then Relationships between them
- Code reuse, easy Maintenance
13
![Page 14: software engineering notes](https://reader034.vdocuments.us/reader034/viewer/2022042700/557202464979599169a340be/html5/thumbnails/14.jpg)
Evolution of Software Design Techniques
Exploratory Style
Control Flow Oriented
Data Structure Oriented
Data Flow Oriented
Object Oriented14
![Page 15: software engineering notes](https://reader034.vdocuments.us/reader034/viewer/2022042700/557202464979599169a340be/html5/thumbnails/15.jpg)
Need of Software EngineeringAnalogy with bridge building:
Over a stream = easy, one person jobOver River Severn … ? (the techniques do not scale)
Problem :
complexity
Many sources, but size is key:UNIX contains 4 million lines of codeWindows 2000 contains 108 lines of code
Software engineering is about managing this complexity!!
15
![Page 16: software engineering notes](https://reader034.vdocuments.us/reader034/viewer/2022042700/557202464979599169a340be/html5/thumbnails/16.jpg)
Attributes of good software?The software should deliver the required functionality and performance to the user and should be maintainable, dependable and usable
MaintainabilitySoftware must evolve to meet changing needs
DependabilitySoftware must be trustworthy
EfficiencySoftware should not make wasteful use of system resources
UsabilitySoftware must be usable by the users for which it was designed
16
![Page 17: software engineering notes](https://reader034.vdocuments.us/reader034/viewer/2022042700/557202464979599169a340be/html5/thumbnails/17.jpg)
Software Myths:
Myth: A traditional story accepted as history; serves to explain the world view of a people
-Software standards provide software engineers with all the guidance they need. The reality is that the standards may be outdated and rarely referred to
17
- People with modern computers have all the software development tools . The reality is that CASE tools are more important than hardware to producing high quality software, yet they are rarely used effectively
![Page 18: software engineering notes](https://reader034.vdocuments.us/reader034/viewer/2022042700/557202464979599169a340be/html5/thumbnails/18.jpg)
Software Myths:- Adding people is a good way to catch up when a project is behind schedule. The reality is that adding people only helps the project schedule when it is done in a planned well coordinated manner- Giving software projects to outside parties to develop solves software project management problems. The reality is people who cant manage internal software development problems will struggle to manage or control the external development of software too
18
- A general statement of objectives from the customer is all that is needed to begin a software project. The reality is without constant communication between customer and developers it is impossible to build a software product that meets the customers real needs
![Page 19: software engineering notes](https://reader034.vdocuments.us/reader034/viewer/2022042700/557202464979599169a340be/html5/thumbnails/19.jpg)
Software Myths:- Once a program is written , the software engineers work is finished. The reality is that maintaining a piece of software is never done, until the software product is retired form service- There is no way to assess the quality of a piece of software until it is actually running on some machine. The reality is that one of the most effective quality assurance practices (FTR) can be applied to any software design product and can serve as a quality filter very early in the product life cycle
19
- The only deliverable from a successful software project is the working program. The reality is the working program is only one of several deliverables that arise from a well managed software project.
![Page 20: software engineering notes](https://reader034.vdocuments.us/reader034/viewer/2022042700/557202464979599169a340be/html5/thumbnails/20.jpg)
Software Myths:- Software engineering is all about the creation of large and unnecessary documentationThe reality is that software engineering is concerned with creating quality.- Project requirements change continually and change is easy to accommodate in the software design. The reality is that every change has far reaching an unexpected consequence.
20
![Page 21: software engineering notes](https://reader034.vdocuments.us/reader034/viewer/2022042700/557202464979599169a340be/html5/thumbnails/21.jpg)
Software Application Types: System software Real time software Business software Engineering and scientific software Embedded software Personal computer software Web based software Artificial intelligence software
21
![Page 22: software engineering notes](https://reader034.vdocuments.us/reader034/viewer/2022042700/557202464979599169a340be/html5/thumbnails/22.jpg)
How Programs Are Usually Written …
Requirements specification was defined like this
The developers understood
it in that way
This is how problem was solved before.
This is how problem is solved now
That is program after debugging
This is how program is described by
marketing department
This, in fact, is what the customer wanted … ;-)
22
![Page 23: software engineering notes](https://reader034.vdocuments.us/reader034/viewer/2022042700/557202464979599169a340be/html5/thumbnails/23.jpg)
Software Process
set of activities whose goal is development or evolution of software
Specification - what the system should do and its development constraints
Development - production of software system
Validation - checking that the software is what the customer wants
Evolution - changing the software in response to changing demands
Generic activities in all
software processes
23
![Page 24: software engineering notes](https://reader034.vdocuments.us/reader034/viewer/2022042700/557202464979599169a340be/html5/thumbnails/24.jpg)
Umbrella activities (SQA, SCM and management) overlays software process model
24
![Page 25: software engineering notes](https://reader034.vdocuments.us/reader034/viewer/2022042700/557202464979599169a340be/html5/thumbnails/25.jpg)
Software Process Models (Software Engineering Paradigm) Development strategy that
covers the process, methods and tools
Software development can be considered as a problem solving loop
25
![Page 26: software engineering notes](https://reader034.vdocuments.us/reader034/viewer/2022042700/557202464979599169a340be/html5/thumbnails/26.jpg)
Types of software process models :
Linear Sequential Model (Water Fall Model)
Prototyping Model RAD Model Evolutionary Model Incremental Model Spiral Model Win-Win Spiral Model Concurrent Development Model Component Based Development Formal Methods Models Fourth Generation Technology Models
26
![Page 27: software engineering notes](https://reader034.vdocuments.us/reader034/viewer/2022042700/557202464979599169a340be/html5/thumbnails/27.jpg)
1. Waterfall model phases
(Linear Sequential Model)A systematic, sequential approach to a software engineering which starts at system information engineering level and progresses through analysis, design, coding, testing and maintenance phase
Modeled after conventional engineering cycles
Theoretical Way of Developing Software?? 27
![Page 28: software engineering notes](https://reader034.vdocuments.us/reader034/viewer/2022042700/557202464979599169a340be/html5/thumbnails/28.jpg)
Waterfall Model Phases System Information
Engineering and Modeling - Starts by establishing requirements for all system elements and then allocating some subset of these requirements to software- Interfaces with hardware, people database etc apart from software elements
28
![Page 29: software engineering notes](https://reader034.vdocuments.us/reader034/viewer/2022042700/557202464979599169a340be/html5/thumbnails/29.jpg)
a. Software Requirement Analysis- Requirement gathering process is
intensified and focused specially on software- Study of information domain- Requirements for system and software must be determined and reviewed with customer
29
Waterfall Model Phases
![Page 30: software engineering notes](https://reader034.vdocuments.us/reader034/viewer/2022042700/557202464979599169a340be/html5/thumbnails/30.jpg)
b. Design- It is a multi step process to address various aspects to be implemented such as data structures , software architecture, interface representation , procedural (algorithmic details) etc- It translates requirements into representation of the software which can be assessed before the code generation - Design document is also a part of the software configuration 30
Waterfall Model Phases
![Page 31: software engineering notes](https://reader034.vdocuments.us/reader034/viewer/2022042700/557202464979599169a340be/html5/thumbnails/31.jpg)
c. Code generation - Design translated into a machine readable formd. Testing - It focuses on the logical intervals of the software (all statements) and functional externals of the software , tests to uncover errors- Basic objective: Defined input should produce desired output
31
Waterfall Model Phases
![Page 32: software engineering notes](https://reader034.vdocuments.us/reader034/viewer/2022042700/557202464979599169a340be/html5/thumbnails/32.jpg)
f.Maintenance and Support- Corrective Maintenance- Perfective Maintenance- Adaptive Maintenance
Source code, Executable, Design documents, SRS, Test cases etc
Change in user requirements
Software Configuration
Items (SCI)
32
Waterfall Model Phases
![Page 33: software engineering notes](https://reader034.vdocuments.us/reader034/viewer/2022042700/557202464979599169a340be/html5/thumbnails/33.jpg)
Waterfall Model(Linear Sequential Model)
33
![Page 34: software engineering notes](https://reader034.vdocuments.us/reader034/viewer/2022042700/557202464979599169a340be/html5/thumbnails/34.jpg)
Drawback : Difficulty of accommodating change after the process is underway
Appropriate when requirements are wellunderstood
34
Waterfall Model Phases
![Page 35: software engineering notes](https://reader034.vdocuments.us/reader034/viewer/2022042700/557202464979599169a340be/html5/thumbnails/35.jpg)
Prototyping Model
What is to be done or
what to explain (objective of software?)
Input? Output?
?
Efficiency of algorithm,
adaptability , interfaces
?
?
Customer Developer
35
![Page 36: software engineering notes](https://reader034.vdocuments.us/reader034/viewer/2022042700/557202464979599169a340be/html5/thumbnails/36.jpg)
Prototyping Model Requirements Gathering :
Define overall system objective
Track all known requirementsOutline areas of further
developmentQuick Design Approach:
Results in all user visible aspects (input approach, output formats etc)
Construction of a Prototype :Evaluated by the
customer/userSpecify refinements in
requirements
36
![Page 37: software engineering notes](https://reader034.vdocuments.us/reader034/viewer/2022042700/557202464979599169a340be/html5/thumbnails/37.jpg)
Prototyping Model
37
![Page 38: software engineering notes](https://reader034.vdocuments.us/reader034/viewer/2022042700/557202464979599169a340be/html5/thumbnails/38.jpg)
Prototyping Model
* Prototype serves as a tool to identify software requirements
* Working prototypes are built from existing program fragments or tools , libraries etc
Once done, what to do with working prototypes?
38
![Page 39: software engineering notes](https://reader034.vdocuments.us/reader034/viewer/2022042700/557202464979599169a340be/html5/thumbnails/39.jpg)
Types of Prototyping
Open Ended PrototypingClosed Ended Prototyping
39
![Page 40: software engineering notes](https://reader034.vdocuments.us/reader034/viewer/2022042700/557202464979599169a340be/html5/thumbnails/40.jpg)
Problematic Aspects of Prototyping
Customer
Developer
I want a working version of my software immediately!!
I am not done yet! I only have a prototype ready!!
40
![Page 41: software engineering notes](https://reader034.vdocuments.us/reader034/viewer/2022042700/557202464979599169a340be/html5/thumbnails/41.jpg)
Problematic Aspects of Prototyping
OK!! Just apply a few fixes to the prototype to make it a working product!!
I’ll have to make some implementation compromise to get the prototype work quickly
Customer
Developer
41
![Page 42: software engineering notes](https://reader034.vdocuments.us/reader034/viewer/2022042700/557202464979599169a340be/html5/thumbnails/42.jpg)
Problematic aspects of Prototyping
Inappropriate OS or programming language may be used because it is available and known to the developer
Inefficient algorithms may be implemented
The less than ideal choice may become an integral part of the system!!
42
![Page 43: software engineering notes](https://reader034.vdocuments.us/reader034/viewer/2022042700/557202464979599169a340be/html5/thumbnails/43.jpg)
The RAD Model (Rapid Application Development)
Primarily used for information system applications
If requirements are well understood , and modularized , RAD process develops fully functional system within 60 to 90 days
43
![Page 44: software engineering notes](https://reader034.vdocuments.us/reader034/viewer/2022042700/557202464979599169a340be/html5/thumbnails/44.jpg)
Phases of RAD process
Business Modeling: Models information flow among business functions, various input process, output aspects of information Data Modeling: Phase one is redefined into a set of data objects that takes part in business activity ( information process)
Process Modeling: The data objects are transformed thru processing to achieve the information flow
Application Generation : RAD model makes use of fourth generation techniques reuses existing a program comp0nents wherever possible any other automated tools to speed up the development process
Testing and turn over: Testing overhead is reduced due to reusability only the new components need testing
44
![Page 45: software engineering notes](https://reader034.vdocuments.us/reader034/viewer/2022042700/557202464979599169a340be/html5/thumbnails/45.jpg)
Phases of RAD process
45
![Page 46: software engineering notes](https://reader034.vdocuments.us/reader034/viewer/2022042700/557202464979599169a340be/html5/thumbnails/46.jpg)
Drawbacks of RAD Model:Very High Human resource requirement overhead Customer and developer both should be committed
All types of application are not appropriate for development under RAD strategy
46
![Page 47: software engineering notes](https://reader034.vdocuments.us/reader034/viewer/2022042700/557202464979599169a340be/html5/thumbnails/47.jpg)
Evolutionary Software Process Models:
47
Linear sequential model is meant for straight line (linear) development approach (delivers a complete product)
Prototyping helps the customer to understand the system requirements
![Page 48: software engineering notes](https://reader034.vdocuments.us/reader034/viewer/2022042700/557202464979599169a340be/html5/thumbnails/48.jpg)
Evolutionary Software Process Models:
48
Evolutionary models are inherently iterative in nature
It helps to develop increasingly more complete versions of the target software
![Page 49: software engineering notes](https://reader034.vdocuments.us/reader034/viewer/2022042700/557202464979599169a340be/html5/thumbnails/49.jpg)
49
Evolutionary Software Process Models:
Business and product requirement changes as the development proceeds Straight path to end product becomes unrealistic
Why models that accommodate product evolution?
Tight market deadline Limited version to be introduced
System requirements are well understood but details of product extensions or system extensions are not known
![Page 50: software engineering notes](https://reader034.vdocuments.us/reader034/viewer/2022042700/557202464979599169a340be/html5/thumbnails/50.jpg)
50
Types of Evolutionary Software Process Models:
- Incremental Model - Spiral Model- Win Win Spiral Model- Concurrent development Model
![Page 51: software engineering notes](https://reader034.vdocuments.us/reader034/viewer/2022042700/557202464979599169a340be/html5/thumbnails/51.jpg)
Incremental Model
51
It is a combination of linear sequential model philosophy with the iterative philosophy of prototyping paradigmThe model is outlined pictorially as belowExample of Incremental Model: Word processing SoftrwareFirst Increment: the core product (Basic Word Processing Application Software
Basic WP requirements are addressedSupplementary features (Known + unknown) are not deliveredCore is used by the customer (undergoes detailed review)Helps to plan next development in order to better meet customers need and delivery of additional features and functionality
![Page 52: software engineering notes](https://reader034.vdocuments.us/reader034/viewer/2022042700/557202464979599169a340be/html5/thumbnails/52.jpg)
Subsequent increments: This process is repeated each time until the complete product is produced (final version)
Each increment is a stripped down version of the final product
Each version fulfills users need and provides a platform for evaluation by the user and hence for their development
52
![Page 53: software engineering notes](https://reader034.vdocuments.us/reader034/viewer/2022042700/557202464979599169a340be/html5/thumbnails/53.jpg)
Benefits: Low manpower requirement Early increments can be
implemented with fewer people Increments can be planned to
manage various technical risk (change in hardware platform , OS features etc)
53
![Page 54: software engineering notes](https://reader034.vdocuments.us/reader034/viewer/2022042700/557202464979599169a340be/html5/thumbnails/54.jpg)
54
![Page 55: software engineering notes](https://reader034.vdocuments.us/reader034/viewer/2022042700/557202464979599169a340be/html5/thumbnails/55.jpg)
4 b. Spiral Model (Proposed by Bohem) This evolutionary software process model
combines the iterative nature of prototyping model , the control and systematic aspect of linear sequential model
It has potential for rapid development of incremental versions of the software
Software is developed in a series of incremental releases Early stage increments: paper model or
prototype Subsequent stage releases: more complete
version of required software55
![Page 56: software engineering notes](https://reader034.vdocuments.us/reader034/viewer/2022042700/557202464979599169a340be/html5/thumbnails/56.jpg)
Spiral Model is divided into a number of Frame Work Activities or Task Regions .
There are six task regions or frame work activities:
Customer Communication: Task for effective communication between customer and developer
ii. Planning : Task is to define resources, timeline and other project related information
iii. Risk analysis: the task is to assess technical and management risks
iv. Engineering: task required to build one or more representations of the application
56
![Page 57: software engineering notes](https://reader034.vdocuments.us/reader034/viewer/2022042700/557202464979599169a340be/html5/thumbnails/57.jpg)
Construction and release: task to construct, test, install and provide support (documentation, training etc)
Customer evaluation: task is to obtain customer feedback or evaluation (engineering stage versus implementation stage)
Spiral model handles the software development process in phase manner, each phase being treated as a project work
Spiral model divides the development process into four projects:
57
![Page 58: software engineering notes](https://reader034.vdocuments.us/reader034/viewer/2022042700/557202464979599169a340be/html5/thumbnails/58.jpg)
58
![Page 59: software engineering notes](https://reader034.vdocuments.us/reader034/viewer/2022042700/557202464979599169a340be/html5/thumbnails/59.jpg)
Each region is populated by a series of tasks specific to the nature of the project
In all cases , umbrella activities are applied (SCM and SQA)
All the stages iterative in nature: First Iteration: Results in production
of product specification Second Iteration: Results in
production of product prototype Next Iteration: Results in production
of progressively more sophisticated versions of the software
59
![Page 60: software engineering notes](https://reader034.vdocuments.us/reader034/viewer/2022042700/557202464979599169a340be/html5/thumbnails/60.jpg)
Each pass thru the planning region two results in adjustment to the project plan
Cost and schedule adjusted on the basis of customer evaluation
Project manager adjusts the number of iterations to complete the software
Classical model ends when the software is delivered. Spiral model can be applied thru out the life of the software
Each project in the Spiral model has a starting point in the project entry point axis, which represents the start of a different type of project
Spiral model remains active until the software retires
60
![Page 61: software engineering notes](https://reader034.vdocuments.us/reader034/viewer/2022042700/557202464979599169a340be/html5/thumbnails/61.jpg)
Spiral model is a realistic approach to development of large scale projects
Spiral model uses Prototyping as a Risk Reduction mechanism. Prototyping is applied at any stage of the product
It incorporated systematic approach as suggested by classical life cycle of software in an iterative way (frame-work)
It demands direct consideration of technical risk Discussions: Difficult to convince customer that evolutionary
approach is controllable High expertise is required to assess considerable risk This is a new model not used widely as linear
sequential development approach It will take number of years before the effectiveness
of this model is known
61
![Page 62: software engineering notes](https://reader034.vdocuments.us/reader034/viewer/2022042700/557202464979599169a340be/html5/thumbnails/62.jpg)
4 c. Win-Win Spiral Model Spiral model suggests customer communication to
decide upon project requirements form customer Developer asks what is required and customer
provides necessary details In reality, developer negotiates with customer for
functionality , performance, and other product /system features against cost and time to market
Negotiation is successful at Win-Win state: Customer wins by getting a product /system
that satisfies majority of his requirements Developer wins by deadline target and
achievable budget
62
![Page 63: software engineering notes](https://reader034.vdocuments.us/reader034/viewer/2022042700/557202464979599169a340be/html5/thumbnails/63.jpg)
63
![Page 64: software engineering notes](https://reader034.vdocuments.us/reader034/viewer/2022042700/557202464979599169a340be/html5/thumbnails/64.jpg)
Negotiation takes place at the beginning of each pass around the spiral , involving the following activities:
Identification of the key stake holders of the system/sub systems Determination of the stake holder’s win
condition Negotiation of the stake holder’s win
condition to fit into a set of Win-Win conditions
for all concerned (including software development project team)
64
![Page 65: software engineering notes](https://reader034.vdocuments.us/reader034/viewer/2022042700/557202464979599169a340be/html5/thumbnails/65.jpg)
4 d. Concurrent Development Model (by Davis and Sitaram) Project managers tracking status of major
phases of a project have no idea of project status since personnel are associated with more than one activity - might be writing SRS , doing design , coding , testing etc. all simultaneously
This shows existence of concurrency of activities occurring in any one phase (requirements change during late development) which can be represented by notations to represent the state of a process (state chart)
Existence of concurrency of activities affect the time bound nature of software development process
65
![Page 66: software engineering notes](https://reader034.vdocuments.us/reader034/viewer/2022042700/557202464979599169a340be/html5/thumbnails/66.jpg)
66
![Page 67: software engineering notes](https://reader034.vdocuments.us/reader034/viewer/2022042700/557202464979599169a340be/html5/thumbnails/67.jpg)
Representation: Any state of a concurrent process model can be
represented schematically as a series of major technical activities, tasks and associated states e.g. analysis, activity can be represented as shown
All activities resides concurrently but resides in different states
For a Spiral Model : When customer communication activity completed the first
iteration and is in state three the analysis activity makes a transition from state one to state two.
Now as a part of customer communication activity , the customer signals a change in requirement , analysis activity makes a move to state three
Concurrent process model defines a series of events that will trigger transition from state to state for each software engineering activity
In general this model is used as a paradigm for client server applications which comprises of a set of functional components
67
![Page 68: software engineering notes](https://reader034.vdocuments.us/reader034/viewer/2022042700/557202464979599169a340be/html5/thumbnails/68.jpg)
Concurrent development model defines client/server applications in two dimensions:
System Dimensions: involves three activities (design, assembly, use) Component dimensions: involves two
activities (design and realization) Concurrency is achieved in two ways: i. System and component activities
can be concurrently taking place (a state oriented approach)
ii. Design and realization of many components can take place concurrently
68
![Page 69: software engineering notes](https://reader034.vdocuments.us/reader034/viewer/2022042700/557202464979599169a340be/html5/thumbnails/69.jpg)
Comments: Applicable to all types of software
developments Helps to figure out the actual
picture of the state of the project Instead of showing software
engineering activities as a sequence of tasks it defines a network of activities existing simultaneous with other activities
Events generated in one activity may trigger a state transition of an activity
69
![Page 70: software engineering notes](https://reader034.vdocuments.us/reader034/viewer/2022042700/557202464979599169a340be/html5/thumbnails/70.jpg)
5. Component Assembly Model Component Assembly model is based on the
principle of Object Oriented Technology OOT emphasizes creation of class that
encapsulates both data and the algorithm (code) that are used to manipulate the data
OOT provides very high level of reusability Component assembly model resembles
spiral model It is evolutionary in nature and uses
iterative approach to develop software It composes applications from prepackaged
software components (class)
70
![Page 71: software engineering notes](https://reader034.vdocuments.us/reader034/viewer/2022042700/557202464979599169a340be/html5/thumbnails/71.jpg)
71
![Page 72: software engineering notes](https://reader034.vdocuments.us/reader034/viewer/2022042700/557202464979599169a340be/html5/thumbnails/72.jpg)
Accomplished by examining the data that are to be manipulated by the application and the algorithms that will be applied to accomplish manipulation these data and code are packaged to form a software component or a class
Old classes are stored in class libraries This model leads to software reuse Reusability provides measurable benefits
to software engineering processes QSM Inc. report indicates: 70% reduction in development cycle time 84% reduction in project cost 26.2% productivity index versus 16.9 as
industry norm
72