Unit 3

Software Engineering UNIT-1
SOFTWARE PROCESS
Introduction S/W Engineering Paradigm life cycle models (water fall, incremental, spiral, WINWIN spiral, evolutionary, prototyping, object oriented) - system engineering computer based system verification validation life cycle process development process system engineering hierarchy.
What is Software?
Software is a set of items or objects that form a configuration that includes programs documents data ...
(Source: Pressman, R. Software Engineering: A Practitioners Approach. McGraw-Hill, 2005)
What is Software?
The basic software have following characteristics: Software is engineered Software doesnt wear out Software is complex
software is engineered
Software is developed or engineered, it is not manufactured in the classical sense.
software doesnt wear out
Software Applications
system software real-time software(application sw) business software engineering/scientific software embedded software PC software AI software WebApps (Web applications)
Goals/ Objectives of Software Engineering
Satisfy user requirements High reliability Low Maintenance costs Delivery on time Low production costs High Performance Ease of use
(Source: Pressman, R. Software Engineering: A Practitioners Approach. McGraw-Hill, 2005) 7
Software engineering
Software engineering (SE) is the application of a systematic, disciplined, quantifiable approach to the design, development, operation, and maintenance of software, and the study of these approaches; that is, the application of engineering to software. The computer science discipline concerned with developing large applications. Software engineering covers not only the technical aspects of building software systems, but also management issues, such as directing programming teams, scheduling, and budgeting.
(Source1: Pressman, R. Software Engineering: A Practitioners Approach. McGraw-Hill, 2005) Source2:
Wikipedia
Cont..
A systematic approach to the analysis, design, implementation and maintenance of software. Software engineering is the engineering discipline through which software is developed. Commonly the process involves finding out what the client wants, composing this in a list of requirements, designing an architecture capable of supporting all of the requirements, designing, coding, testing and integrating the separate parts, testing the whole, deploying and maintaining the software. Programming is only a small part of software engineering.
(Source: Pressman, R. Software Engineering: A Practitioners Approach. McGraw-Hill, 2005) Source1
: Wikipedia
Cont..
The Software Engineering Body of Knowledge (SWEBOK) divides software engineering into 10 knowledge areas: Software requirements Software design Software construction Software testing Software maintenance Software configuration management Software engineering management Software engineering process Software engineering tools and methods Software quality
Wikipedia
10
(Source: Pressman, R. Software Engineering: A Practitioners Approach. McGraw-Hill, 2005) Source:
A Layered Technology
Software Software Engineering Engineering tools methods process model
a quality focus
11
Process Flow
12
Process Flow
Linear process flow executes each of the five activities in sequence. An iterative process flow repeats one or more of the activities before proceeding to the next. An evolutionary process flow executes the activities in a circular manner. Each circuit leads to a more complete version of the software. A parallel process flow executes one or more activities in parallel with other activities ( modeling for one aspect of the software in parallel with construction of another aspect of the software. )
S/W Engineering Paradigm or process

The software development strategy is referred as Software Engineering Paradigm. The software development strategy consists of methods, tools, and procedures. There exist various software development strategies or process models.
14
Software Development Models (or) process models

Software Development Models Water Fall Model Incremental process model Incremental Model RAD (Rapid Application Development) Model Evolutionary Process models: Spiral Model WINWIN Spiral Model Prototyping model Object oriented Model Each model has its own specific steps for software development . A suitable development model is selected by considering several factors like requirement , application type, application software to be used for development etc
The Waterfall Model (1)

Sometimes called the classic life cycle Suggests a systematic, sequential (or linear) approach to s/w development The oldest paradigm for s/w engineering Works best when
Requirements of a problem are reasonably well understood Well-defined adaptations or enhancements to an existing system must be made Requirements are well-defined and reasonably stable
The Waterfall Model (2)

Communication project initiation requirements gathering Planning estimating scheduling tracking Modeling analysis design
Construction code test Deployment delivery support feedback
Fig The waterfall model

17
Real time example

We can take real life examples for water fall model like automobile companies make cars and bikes. when they are building a car, the requirements are fixed, predefined. There will be no change in the requirements during the process of building a car. Once we complete a stage, we proceed to the next one. If there is any change in requirements come then we have to go back and make those changes. Then we have to change our complete system that requires extra time and extra money. This is a major disadvantage of water fall model.
Some of other examples are: 1. Online event management system. 2. Material resource planning in a manufacturing unit
18
The Waterfall Model - Problems

Real projects rarely follow the sequential flow
Accommodates iteration indirectly Changes can cause confusion
It is often difficult for the customer to state all requirements explicitly

Has difficulty accommodating the natural uncertainty that exists at the beginning of many projects
The customer must have patience

A working version of the program(s) will not be available until late in the project time-span A major blunder, if undetected until the working program is reviewed, can be disastrous
Leads to blocking states

Incremental Process Models (1)

Communication
Software Functionality and Features
Planning Modeling (analysis, design)
increment # n
Construction (code, test)

Deployment (delivery, feedback) delivery of nth increment
increment # 2
increment # 1 delivery of 1st increment
delivery of 2nd increment
Project Calendar Time

Fig 3.2: The incremental model
20
Incremental Models (2)

Combines elements of the waterfall model applied in an iterative fashion Each linear sequence produces deliverable increments of the software The first increment is often a core product The core product is used by the customer (or undergoes detailed evaluation) Based on evaluation results, a plan is developed for the next increment
Incremental Process Models (3)

The incremental process model, like prototyping and other evolutionary approaches, is iterative in nature But unlike prototyping, the incremental model focuses on the delivery of an operational product with each increment Particularly useful when
Staffing is unavailable
Increments can be planned to manage technical risks

Incremental model example

For Example:
In the diagram above when we work incrementally we are adding piece by piece but expect that each piece is fully finished. Thus keep on adding the pieces until its complete.
RAD(Rapid Application Development)

Rapid Application Development Emphasizes a short development cycle A high speed adaptation of the waterfall model Uses a component-based construction approach components or functions are developed in parallel as if they were mini projects. May deliver software within a very short time period (e.g. , 60 to 90 days) if requirements are well understood and project scope is constrained
24
The RAD Model

Team # n Modeling business modeling data modeling process modeling Construction component reuse Team # 2 automatic code Modeling generation business modeling testing data modeling process modeling Planning Construction component reuse Team # 1 automatic code Modeling generation business modeling testing data modeling process modeling Construction component reuse automatic code generation testing (Source: Pressman, R. Software Engineering: A Practitioners Approach. McGraw -Hill, 2005) Deployment integration delivery feedback
Communication
60 90 days
25
Advantages and disadvantages

Advantages of the RAD model: Reduced development time. Increases reusability of components Quick initial reviews occur Encourages customer feedback Integration from very beginning solves a lot of integration issues. Disadvantages of RAD model: Depends on strong team and individual performances for identifying business requirements. Requires highly skilled developers/designers. High dependency on modeling skills Inapplicable to cheaper projects as cost of modeling and automated code generation is very high. When to use RAD model: RAD should be used when there is a need to create a system that can be modularized in 2-3 months of time. It should be used if theres high availability of designers for modeling and the budget is high enough to afford their cost along with the cost of automated code generating tools.
(Source: Pressman, R. Software Engineering: A Practitioners Approach. McGraw -Hill, 2005)
26
Evolutionary Process Models

Evolutionary Models take the concept of evolution into the engineering paradigm. Therefore Evolutionary Models are iterative. They are built in a manner that enables software engineers to develop increasingly more complex versions of the software. Business and product requirements often change as development proceeds, making a straight-line path to an end product is unrealistic.
27
The Spiral Model (1)

Couples the iterative nature of prototyping with the controlled and systematic aspects of the waterfall model It provides the potential for rapid development of increasingly more complete versions of the software It is a risk-driven process model generator It has two main distinguishing features
Cyclic approach
Incrementally growing a systems degree of definition and implementation while decreasing its degree of risk
A set of anchor point milestones

A combination of work products and conditions that are attained along the path of the spiral
(Source: Pressman, R. Software Engineering: A Practitioners Approach. McGraw -Hill, 2005) 28

Planning
estimation scheduling risk analysis
Communication
Modeling
analysis design Start
Deployment
delivery feedback
Construction
code test
Fig : A typical spiral model
29

Unlike other process models that end when software is delivered, the spiral model can be adapted to apply throughout the life of the computer s/w The circuits around the spiral might represent
Concept development project New Product development project Product enhancement project
The spiral model demands a direct consideration of technical risks at all stages of the project Examples of Spiral model The evolution of Microsoft Operating System, Compilers and other operating systems.
The Spiral Model - Drawbacks

It may be difficult to convince customers (particularly in contract situations) that the evolutionary approach is controllable. It demands considerable risk assessment expertise and relies on this expertise for success. If a major risk is not uncovered and managed, problems will undoubtedly occur.
Win Win Spiral Model

The Win-Win spiral approach is an extension of the spiral approach. The phase in this approach is same as the phase in the spiral approach. The only difference is that at the time of the identifying the requirements, the development team and the customer hold discussion and negotiate on the requirements that need to be included in the current iteration of the software.
The approach is called Win-Win because it is a winning situation for the development team and also for the customer. The customer wins by getting the product that fulfils most of the requirements while the development team wins by delivering software which is developed with all the requirements established after negotiations with the customer. The Win-Win approach is generally used when you have time-bound releases.
Win Win spiral model
33
Prototyping
Q u ick p lan
u i t o Communication
Quick plan
Modeling Quick design
oy t Deployment D e i v y Delivery e ac & Feedback
Construction Co s t r c i n of f r t t pe prototype
Fig : The prototyping model
35
Advantages
1. 2. 3. 4. Iterative process facilitating enhancements. Partial products can be viewed by the customer. Flexibility of the product. Customer satisfaction of the product.
36
Prototyping - Problems
1. Customers may press for immediate delivery of working but inefficient products 2. The developer often makes implementation compromises in order to get a prototype working quickly 3. No optimal solution. 4. Time consuming if the algorithm used is inefficient. 5. Iterative process continues forever which cannot be stopped at a particular stage. 6. Poorer documentation resulting in difficult maintenance.
The Concurrent Development Model (1)

Sometimes called concurrent engineering Can be represented schematically as a series of framework activities, s/w engineering actions and tasks, and their associated states Defines a series of events that will trigger transitions from state to state for each of the s/w engineering activities, actions, or tasks Applicable to all types of s/w development Defines a network of activities Events generated at one point in the process network trigger transitions among the states
The Concurrent Development Model (2)

None
Modeling activity
Under development Awaiting changes
Represents the state of a software engineering activity or task
Under review
Under revision
Baselined
Done
39
System Engineering
- Computer-based system - System engineering process - Business process engineering - Product engineering
(Source: Pressman, R. Software Engineering: A Practitioners Approach. McGraw -Hill, 2005)40
Computer-based System
41
Introduction
Software engineering occurs as a consequence of system engineering System engineering may take on two different forms depending on the application domain
Business process engineering conducted when the context of the work focuses on a business enterprise Product engineering conducted when the context of the work focuses on a product that is to be built
Both forms bring order to the development of computer-based systems Both forms work to allocate a role for computer software and to establish the links that tie software to other elements of a computer-based system
42
System
System
A set or arrangement of things so related as to form a unity or organic whole A set of facts, principles, rules. etc., to show a logical plan linking the various parts A method or plan of classification or arrangement An established way of doing something such as a method or procedure
43
Computer-based System
Defined: A set or arrangement of elements that are organized to accomplish some predefined goal by processing information The goal may be to support some business function or to develop a product that can be sold to generate business revenue A computer-based system makes use of system elements Elements constituting one system may represent one macro element of a still larger system Example
A factory automation system may consist of a numerical control machine, robots, and data entry devices; each can be its own system At the next lower hierarchical level, a manufacturing cell is its own computerbased system that may integrate other macro elements
The role of the system engineer is to define the elements of a specific computer-based system in the context of the overall hierarchy of systems
A computer-based system makes use of the following four system elements that combine in a variety of ways to transform information
Software: computer programs, data structures, and related work products that serve to effect the logical method, procedure, or control that is required Hardware: electronic devices that provide computing capability, interconnectivity devices that enable flow of data, and electromechanical devices that provide external functions People: Users and operators of hardware and software Database: A large, organized collection of information that is accessed via software and persists over time
Computer-based System (continued)
The uses of these elements are described in the following:

Documentation: Descriptive information that portrays the use and operation of the system Procedures: The steps that define the specific use of each system element or the procedural context in which the system resides
45
System Engineering Process
46
System Engineering Process

The system engineering process begins with a world view; the business or product domain is examined to ensure that the proper business or technology context can be established The world view is refined to focus on a specific domain of interest Within a specific domain, the need for targeted system elements is analyzed Finally, the analysis, design, and construction of a targeted system element are initiated At the world view level, a very broad context is established At the bottom level, detailed technical activities are conducted by the relevant engineering discipline (e.g., software engineering)
"Always design a thing by considering it in its next larger context a chair in a room, a room in a house, a house in an environment, and environment in a city plan"
System Engineering Hierarchy
48
Cont..
Stated in a slightly more formal manner, the world view (WV) is composed of a set of domains (Di), which can each be a system or system of systems in its own right. WV = {D1, D2, D3, . . . , Dn} Each domain is composed of specific elements (Ej) each of which serves some role in accomplishing the objective and goals of the domain or component: Di = {E1, E2, E3, . . . , Em} Finally, each element is implemented by specifying the technical components (Ck) that achieve the necessary function for an element. Ej = {C1, C2, C3, . . . , Ck}
System Modeling (at each view level)

Defines the processes (e.g., domain classes in OO terminology) that serve the needs of the view under consideration Represents the behavior of the processes and the assumptions on which the behavior is based Explicitly defines intra-level and inter-level input that form links between entities in the model Represents all linkages (including output) that will enable the engineer to better understand the view May result in models that call for one of the following
Completely automated solution A semi-automated solution A non-automated (i.e., manual) approach
50
Factors to Consider when Constructing a Model

Assumptions
These reduce the number of possible variations, thus enabling a model to reflect the problem in a reasonable manner
Simplifications
These enable the model to be created in a timely manner
Limitations
These help to bound the maximum and minimum values of the system
Constraints
These guide the manner in which the model is created and the approach taken when the model is implemented
Preferences
These indicate the preferred solution for all data, functions, and behavior They are driven by customer requirements
Optimization of some of these factors may be mutually exclusive

System Modeling with UML

The Uniform Modeling Language (UML) provides diagrams for analysis and design at both the system and software levels Examples
Use case diagrams Activity diagrams Class diagrams State diagrams
52
Different Views
Users
Designers
Analyzers
53
Use case diagram

System boundary
Actor
overview the usage requirements presentations project stakeholders "the meat" of the actual requirements Use case: System boundary: Actor:
Use case
indicates A use case the describes scope of ayour sequence An actor is a person, organization, of system. Anything that provide within the box or actions external system that something plays a of represents measurable functionality value to an that actor is in role in one or more interactions and scope drawn and anything as a horizontal outside the with is your system ellipse box is not
Online C2C shopping
54
Class Diagram
Name Class diagrams show the classes of the system, their interrelationships (including inheritance, aggregation, and association), and the operations and attributes of the classes.
Aggregation Generalization
Associations
Relations
Attribute s Operation s
55
Sequence Diagram
Object: Class
A sequence diagram is An interaction diagram that details how operations are carried out. What messages are sent and when. Sequence diagrams are organized according to time
Message Operations
Lifeline
56
Activities Diagram
Start Fork Activity diagrams describe the workflow behaviour of a system
Branch
Merge
Joint
57
End
State Machine Diagram

A State Machine diagram shows the possible states of the object and the transitions that cause a change in state.
58
Business Process Engineering
59
Business Process Engineering

Business process engineering defines architectures that will enable a business to use information effectively It involves the specification of the appropriate computing architecture and the development of the software architecture for the organization's computing resources Three different architectures must be analyzed and designed within the context of business objectives and goals
The data architecture provides a framework for the information needs of a business (e.g., ERD) The application architecture encompasses those elements of a system that transform objects within the data architecture for some business purpose The technology infrastructure provides the foundation for the data and application architectures
It includes the hardware and software that are used to support the applications and data
61
Product Engineering
62
Product Engineering
Product engineering translates the customer's desire for a set of defined capabilities into a working product. It achieves this goal by establishing a product architecture and a support infrastructure Product architecture components consist of people, hardware, software, and data Support infrastructure includes the technology required to tie the components together and the information to support the components
63
Cont..
Requirements engineering elicits the requirements from the customer and allocates function and behavior to each of the four components System component engineering happens next as a set of concurrent activities that address each of the components separately Each component takes a domain-specific view but maintains communication with the other domains The actual activities of the engineering discipline takes on an element view Analysis modeling allocates requirements into function, data, and behavior Design modeling maps the analysis model into data/class, architectural, interface, and component design
64
Product Engineering Hierarchy

Product Requirements Engineering Human Hardware Software Engineering Engineering Engineering
Data and Classes
Database Engineering
System Component Engineering Analysis Modeling Design Modeling
Function
Behavior
Data/Class Design
Architectural Design
Interface Design
Component Design
Construction
Verification & Validation

Verification:
"Are we building the product right. The software should conform to its specification.
Validation:
"Are we building the right product". The software should do what the user really requires.
66
The V & V process

Is a whole life-cycle process - V & V must be applied at each stage in the software process. Has two principal objectives
The discovery of defects in a system; The assessment of whether or not the system is useful and useable in an operational
67
V& V goals
Verification and validation should establish confidence that the software is fit for purpose. This does NOT mean completely free of defects. Rather, it must be good enough for its intended use and the type of use will determine the degree of confidence that is needed.

Unit 3

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Unit 3

Hochgeladen von

Copyright:

Verfügbare Formate

Software Engineering UNIT-1

(Source: Pressman, R. Software Engineering: A Practitioners Approach. McGraw-Hill, 2005)

(Source: Pressman, R. Software Engineering: A Practitioners Approach. McGraw-Hill, 2005)

(Source: Pressman, R. Software Engineering: A Practitioners Approach. McGraw-Hill, 2005)

software doesnt wear out

(Source: Pressman, R. Software Engineering: A Practitioners Approach. McGraw-Hill, 2005)

(Source: Pressman, R. Software Engineering: A Practitioners Approach. McGraw-Hill, 2005)

Goals/ Objectives of Software Engineering

(Source: Pressman, R. Software Engineering: A Practitioners Approach. McGraw-Hill, 2005) Source:

(Source: Pressman, R. Software Engineering: A Practitioners Approach. McGraw-Hill, 2005)

(Source: Pressman, R. Software Engineering: A Practitioners Approach. McGraw-Hill, 2005)

S/W Engineering Paradigm or process

(Source: Pressman, R. Software Engineering: A Practitioners Approach. McGraw-Hill, 2005)

Software Development Models (or) process models

The Waterfall Model (1)

The Waterfall Model (2)

Construction code test Deployment delivery support feedback

Fig The waterfall model

Real time example

(Source: Pressman, R. Software Engineering: A Practitioners Approach. McGraw-Hill, 2005)

The Waterfall Model - Problems

It is often difficult for the customer to state all requirements explicitly

The customer must have patience

Leads to blocking states

Incremental Process Models (1)

Software Functionality and Features

Planning Modeling (analysis, design)

Construction (code, test)

delivery of 2nd increment

Project Calendar Time

Incremental Models (2)

Incremental Process Models (3)

Increments can be planned to manage technical risks

Incremental model example

RAD(Rapid Application Development)

The RAD Model

Advantages and disadvantages

(Source: Pressman, R. Software Engineering: A Practitioners Approach. McGraw -Hill, 2005)

Evolutionary Process Models

(Source: Pressman, R. Software Engineering: A Practitioners Approach. McGraw -Hill, 2005)

The Spiral Model (1)

A set of anchor point milestones

The Spiral Model (2)

Fig : A typical spiral model

The Spiral Model (3)

The Spiral Model - Drawbacks

Win Win Spiral Model

Win Win spiral model

(Source: Pressman, R. Software Engineering: A Practitioners Approach. McGraw -Hill, 2005)

Modeling Quick design

oy t Deployment D e i v y Delivery e ac & Feedback

(Source: Pressman, R. Software Engineering: A Practitioners Approach. McGraw-Hill, 2005)

Fig : The prototyping model

(Source: Pressman, R. Software Engineering: A Practitioners Approach. McGraw -Hill, 2005)

The Concurrent Development Model (1)

The Concurrent Development Model (2)

Under development Awaiting changes

Represents the state of a software engineering activity or task

(Source: Pressman, R. Software Engineering: A Practitioners Approach. McGraw-Hill, 2005)

(Source: Pressman, R. Software Engineering: A Practitioners Approach. McGraw -Hill, 2005)40

(Source: Pressman, R. Software Engineering: A Practitioners Approach. McGraw-Hill, 2005)

(Source: Pressman, R. Software Engineering: A Practitioners Approach. McGraw-Hill, 2005)

(Source: Pressman, R. Software Engineering: A Practitioners Approach. McGraw-Hill, 2005)

Computer-based System (continued)