Transcript Lecture 2.ppt

Lecture 2
COMSATS Islamabad
Enterprise
Systems
Development
(CSC447)
Muhammad Usman, Assistant Professor
CIIT
Confusion with Programs and Products
Programs
Software Products
Usually small in size
Large
Author himself is sole
user
Large number of users
Single developer
Team of developers
Lacks proper user
interface
Well-designed interface
Lacks proper
documentation
Well documented & usermanual prepared
Ad hoc development
Systematic development
2
Software Programming
≠ Software Engineering
• Software programming: the process of translating a problem
from its physical environment into a language that a computer can
understand and obey. (Webster’s New World Dictionary of Computer
Terms)
– Single developer
– “Toy” applications
– Short lifespan
– Single or few stakeholders
• Architect = Developer = Manager = Tester = Customer =
User
– One-of-a-kind systems
– Built from scratch
– Minimal maintenance
3
Software Programming ≠ Software Engineering
Software engineering
–
–
–
–
Teams of developers with multiple roles
Complex systems
Indefinite lifespan
Numerous stakeholders
• Architect ≠ Developer ≠ Manager ≠ Tester ≠ Customer ≠ User
– System families
– Reuse to amortize costs
– Maintenance accounts for over 60% of overall development
costs
4
Lecture 2
Software Systems and Their Development Life
Cycle
Software Systems
• Software Systems Vs Other Engineering
Artifacts
• Civil Engineers develop roads, bridges etc.
• Electrical Engineers develop circuits, chips etc.
• Aeronautical Engineers develop planes
• Software Engineers develop software systems
Software Engineering Difficulties
• Software engineers deal with unique set of problems
–
–
–
–
Young field with tremendous expectations
Building of vastly complex, but intangible systems
Software is not useful on its own e.g., unlike a car, thus
It must conform to changes in other engineering areas
• Some problems can be eliminated
– These are Brooks’ “accidental difficulties”
• Other problems can be lessened, but not eliminated
– These are Brooks’ “essential difficulties”
7
Essential Difficulties
• Only partial solutions exist for them, if any
• Cannot be abstracted away
– Complexity
– Conformity
– Changeability
– Intangibility
8
Complexity
• No two software parts are alike
– If they are, they are abstracted away into one
• Complexity grows non-linearly with size
(scaling-up)
– E.g., it is impossible to enumerate all states of
program
– Except perhaps “toy” programs
• From complexity comes the difficulty of
– Communication
– Enumerating
– Less understanding of all the possible states of the
program
9
Conformity
• Natural Science – God
VS
Software – People
• Much of the complexity that he (developer)
must master is arbitrary complexity, forced
without rhyme or reason by many human
institutions and systems to which his
interfaces must conform.
• These (standards) differ from interface to
interface, and from time to time, not because
of necessity but only because they were
designed by different people, rather than by
God.
Changeability
• The software entity is constantly subject to
pressures for change. Of course, so are
buildings, cars, and computers. But
manufactured things are infrequently
changed.
• Software of a system embodies its function,
and the function is the part that most feels
the pressure of change
• In part it is because software can be changed
more easily – it is pure thought stuff, infinitely
malleable
Changeability
• Building do in fact get change but the high
cost of change understood by all serve to
dampen the whims of the changes
• The software product is embodied in a cultural
matrix of applications, users, laws, and
machine vehicles. These change continually,
and their changes inevitably force change
upon the software product.
Invisibility
• Software is invisible and un-visualizable.
• A geometric reality is captured in a geometric
abstraction
• The reality of software is not inherently
embedded in space
• As soon as we attempt to diagram software
structure, we find it to constitute not one, but
several, general directed graphs superimposed
one upon another.
• This lack not only obstruct the process of
design within one mind, it severely hinders
communication among minds.
Software Systems
• Software Systems are developed by software
engineers.
• What is software engineering?
• Let us define it first and then we will move on
with development of enterprise software
systems
WHAT IS SOFTWARE ENGINEERING?
 The term S/W Engineering was/is sometimes confusing, firstly because
S/W engineer (some times) work as system programmer, people assume
that the engineering component of the term comes from this source. SO we
have H/W engg and S/W engg.
 Second cause of confusion lies in the fact that there is no generally agreed
definition of software engineering, although many are similar.
 Software Engineering as a term was first coined in 1968 at a NATO
conference in West Germany held to discuss the software crises
 Other definitions such as Fairley’s 1985 explicitly include the concerns of
management in the software development process:
‘Software engineering is the technological and managerial
discipline concerned with systematic production and maintenance
of software products that are developed and modified on time and
within cost estimates.’
15
What is Software Engineering? (2)
"The establishment and use of sound engineering
principles (methods) in order to obtain economically
software that is reliable and works on real machines"
[Bauer 1972].
"cost-effective Software engineering is that form of
engineering that applies the principles of computer
science and mathematics to achieving solutions to
software problems.“ [CMU/SEI-90-TR-003]
"The application of a systematic, disciplined, quantifiable
approach to the development, operation, and
maintenance of software" [IEEE Standard Computer
Dictionary, 610.12, ISBN 1-55937-079-3, 1990].
16
What is Software Engineering? (3)
 Software engineering is concerned with the theories,
methods and tools for developing, managing and
evolving software products. [ I. Sommerville, 6ed.]
 A discipline whose aim is the production of quality
software, delivered on time, within budget, and
satisfying users' needs. (Stephen R. Schach, Software
Engineering, 2ed.)
 The practical application of scientific knowledge in the
design and construction of computer programs and the
associated documentation required to develop, operate
and maintain them [B.W. Boehm]
 Multi-person construction of multi-version software
(Parnas, 1987)
17
So, Software Engineering is …
• Scope
– study of software process, development
principles, techniques, and notations
• Goals
– production of quality software,
– delivered on time,
– within budget,
– satisfying customers’ requirements and users’
needs
18
Concept of Life Cycle
• Software Systems, like other engineering
artifacts, have a lifecycle
• Examples
– Your cell phone has a lifecycle
• We human being also have a life cycle
Review
8
Implementation
7
Maintenance
Feasibility
9
Study
1
System Development
Life Cycle (SDLC)
Testing
6
System
Development
5
System
Specification
2
Outline Design
3
Detailed Design
4
20
Project Life Cycle Perspective
Planning Analysis
Design
Implementation
Testing
Maintenance
Software Configuration Management
Software Engineering/Project Management
Software Engineering Process (CMM)
Software Engineering Tools and Methods
Software Quality
Spring 2010
21
SOFTWARE DEVELOPMENT PROCESS MODELS

Problem solving loop with basic four activities, i.e., problem
analysis, problem definition, technical development and
solution integration.

Regardless of the process model chosen, all the four activities
coexist simultaneously at some level of detail.

A process model is chosen based upon the:

nature of the project,

application,

methods and tools to be used, and

controls and deliverables that are required.
22
The Linear Models
23
(1) The waterfall model

It suggests a systematic, sequential approach to s/w development.
Important features
 All activities are to be performed in an order and one after the
other. The output of one is the input to the other.
 Verification and validation is to be performed after the end of each
phase.
 The inputs & outputs at each phase must be defined (i.e. goal of
each group is defined).
 Once the outputs of a phase are produced (i.e. phase completed) then
these should not be changed as it is input to the other. The certified
output of a phase that is released for the next phase is called a
baseline.
24
Feasibility
Study
Work Tasks &
Work Products
System
Specification
Outline design
Feasibility
Detailed
Design
Report
System
Development
Req. Document
Project Plan
Testing &
Integration
System
Design
Implementation
Document
Det Design
Review
Document
Maintenance
Programs
Test Plans,
Test Reports
And Manuals
Installation
Report
Review
Reports
Supplements
25
25
Limitations of Waterfall Model
1. Limits and freezes the requirements of the system.
•
Suits to the automation of existing manual system.
But having unchanging (or changing few)
requirements is unrealistic for new systems.
2. Freezing requirements may result in purchase of an
obsolete hardware as the software development usually
takes years (and h/w technology is changing fast).
3. Does not support partial system development. This is
specially required as client also plays important role
in the requirement specification.
26
(2) Prototyping

This approach is developed to counter the first two limitations
of the waterfall model.

A customer may define a set of general objectives for software
but does not identify detailed input, processing, or output
requirements.

The developer may be unsure of (1) the efficiency of an
algorithm, (2) the adaptability of an operating system, or (3)
the form the human machine interaction should take.

Instead of freezing the requirements before design, coding can
proceed, a throwaway prototype is built to help understand the
requirements.
27
Prototyping…..

This prototype is based on the currently available requirements and
put on trail.

Although the development of prototype also goes through the
design and coding phases but main stress is not put on formal
procedures.

By using the prototype the user gets the true working environment
of the actual system to be designed and developed later on.

Hence more realistic requirement of the required system are brought
in.

Typically useful for the areas where a system (manual or
automated) does not exist or the overall system is very large and
complex.

Also provides an implemented feasibility, which provides
effective method of demonstration.
28
Requirements Analysis
Design
Code
Test
Design
Code
Test
Disadvantages:

The only drawback seems the duplication of efforts and cost
involved in build-twice approach.
Justifications:




Prototyping need not be very costly and can actually reduce the
overall development cost.
The prototypes are usually not complete systems and many of the
details are not built in.
In addition, cost of testing and writing detail documents is
reduced, which reduces the cost of developing prototype.
Further the experience gained during prototyping is very useful for
developers when developing the final system. This experience also
reduces the cost of development of actual system, and results in
more reliable and better design.
29
Problems to be tackled by Prototyping
 Customer’s misconception (reqcompletion/communication, involvement,
expectations, automation)
 Developer’s wrong habits (Not strict to req,
misunderstanding, assumptions/imaginations)
 Rules of the game are not defined at the
beginning
30
(3) RAD Model

Rapid application development (RAD) is a linear sequential S/W
development process model that emphasizes on extremely short
development cycle.

high-speed RAD is achieved by using a component-based project
construction approach.

If requirements are well understood
and project scope is constrained (i.e.
goals/ are fixed / freezed); the RAD
enables a development team to
create a “fully functional system”
within very short time (e.g. 60-90
days).
31
RAD Phases (1)
1. Business Modeling (Business Processes)
Information flows among business functions is modeled such that
answers the questions:
• What information is generated?
• Who generates it?
• Who processes it?
• Where does the information go?
2. Data Modeling (Entities)
(1) The information flow is refined into a set of data objects that are
needed to support the business.
(2) Characteristics (attributes) of each object are identified and
(3) Relationships between these objects are defined.
32
RAD Phases (2)
3. Process modeling (Processes/Functions)
(1) The data object defined in the data modeling phase are transformed to
achieve the information flow necessary to implement a business function
(i.e. transformation of input-object to output object defines flow of
information in a process/function)
(2) Such processing descriptions are created for adding, modifying, deleting,
or retrieving a data object.
4. Application Generation
(1) RAD is based on the use of 4GT, rather than using 3GL.
(2) RAD process works to re-use existing components (when possible).
(3) Create re-useable components (when necessary). In all cases automated
tools are used to facilitate construction of S/W.
33
RAD Phases (3)
5. Testing and Turnover
(1) Re-use releases from testing, as such components, are already tested.
(2) New components must be tested and all interfaces must be fully
exercised. Optimally,
(3) If a business application can be modularized such that each major
function can be completed in less than 3 months time, each can be
addressed by a separate RAD team, and then integrated (to give
working system in 3-6 months)
Drawbacks
(1) For large scalable projects, RAD requires sufficient human
resources to create right number of RAD teams.
(2)
RAD requires developers & customers committed to complete a
system in a short time frame, other wise if commitment is lacking
from either side, RAD projects will fail.
34
(4) The Incremental Model
OR Iterative Enhancement Model
1. Solves the problem of 3rd limitation of the waterfall
model.
2. Basic idea: software should be developed in
increments; each increment adding some
functionality until the full system is implemented.
3. At each step, extensions and design modifications can
be made .
4. Applies linear sequences in a staggered fashion as
time progresses.
35
increment 1
Analysis Design
increment 2
analysis
increment 3
Code
Test
delivery of 1st increment
design
code
test
analysis
design
code
increment n
analysis
delivery of 2nd increment
design
test
code
delivery of
3rd increment
test
delivery of
nth increment
36
Advantages
1.
2.
Major advantage: it can result in better testing since testing
each increment is likely to be easier than testing the entire
system.
Similar to prototype each increment provides feed back which
is useful for determining further/final requirements of the
system.
3.
Model proceeds in steps starting from the simple and key
aspects of the system.
4.
A project control list is prepared that contains, in order, all the
tasks to be implemented in the final system; provides a better
control and progress monitoring of development.
37
(5) Spiral Model

The activities in this model can be organized like a spiral. The
spiral has many cycles.

The radial dimension represents the commutative
cost incurred in accomplishing the steps done so
far, and

The angular dimension represents the progress
made in completing each cycle of the spiral.
38
(1) Each cycle begins with the identification of objectives and
different alternative possible to achieve the objectives.
(2) In the next step different alternatives are evaluated and
uncertainties and risks are identified.
(3) Next step is to develop strategies that resolve uncertainties of
risks and software development takes place.
(4) Finally the evaluation is made to help plan the next stage.
(5) The spiral is based on risk driven nature, which enables any
mixture of specification-oriented, prototype-oriented, simulationoriented, or some other approach.
39
Features
 Each Cycle is completed with a review, which covers all the
products developed in that cycle.
 Equally useful for development and enhancement projects.
 More cycles can be added to add activities not covered in the
model (e.g. feasibility)
 Provides Project management and planning activities, in addition
to development project.
40
Agile Development
2001: Kent Beck and 16 other software developers,
referred to as “Agile Alliance”, signed the “manifesto for
Agile software development”. It stated:
Through this work we have come to Value:
Individuals and interaction over processes and tool
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following plan
That is, while there is value in the items on the right ,
we values the items on the left more.
41
Agile Methods
 Agile software development is a group of software
development methodologies that are based on similar
principles.
 Agile methodologies generally promote a project
management process that encourages
– frequent inspection and adaptation
– a leadership philosophy that encourages team work
– a set of engineering best practices that allow for rapid
delivery of high-quality software, and a business approach
that aligns development with customer needs and company
goals
42
What are Agile Methods?
Agile software development is a conceptual
framework for undertaking software engineering
projects.
Most agile methods attempt to minimize risk by
developing software in short timeboxes, called
iterations, which may typically last one to four
weeks.
Each iteration is like a miniature software project
of its own, and includes all of the tasks necessary
to release the mini-increment of new
functionality.
43
Agile Methods v/s Traditional Methods
 Agile methods emphasize real time
communication, preferably face-to-face, over
written documents.
 Agile methods like XP relies on the close
collaboration of activity engaged individuals with
ordinary talents and has the ability to flexibly
schedule the implementation of functionality,
responding to changing business needs.
 Reference: Extreme Programming explained:
Embrace Change By: Kent Beck with Cynthia
Andres; 2nd ed., 2005
44
•
•
•
•
•
•
•
•
Different Agile Methods?
Extreme Programming (XP)
Scrum
Agile Modeling
Adaptive Software Development (ASD)
Crystal Clear and Other Crystal Methodologies
Dynamic Systems Development Method (DSDM)
Feature Driven Development
Lean software development
• Agile Unified Process (AUP)
45