Lecture 2 Enterprise Systems Development (CSC447) COMSATS Islamabad Muhammad Usman, Assistant...
-
Upload
evangeline-phelps -
Category
Documents
-
view
230 -
download
6
Transcript of Lecture 2 Enterprise Systems Development (CSC447) COMSATS Islamabad Muhammad Usman, Assistant...
Lecture 2
Enterprise
Systems
Development(CSC447)
COMSATS Islamabad
Muhammad Usman, Assistant Professor CIIT
2
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 & user-manual prepared
Ad hoc development Systematic development
3
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
4
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
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
7
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”
8
Essential Difficulties
• Only partial solutions exist for them, if any• Cannot be abstracted away
– Complexity– Conformity– Changeability– Intangibility
9
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
Conformity• Natural Science – God
VSSoftware – 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
15
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.’
WHAT IS SOFTWARE ENGINEERING?
16
"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].
What is Software Engineering? (2)
17
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)
18
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
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
20
Testing6
Feasibility Study1
Maintenance9
Review8
Implementation7 System
Specification2
System Development5
Detailed Design4
Outline Design 3
System Development Life Cycle (SDLC)
Spring 2010 21
Project Life Cycle Perspective
Planning Analysis DesignImplem-entation
TestingMain-
tenance
Software Configuration Management
Software Engineering/Project Management
Software Engineering Process (CMM)
Software Engineering Tools and Methods
Software Quality
22
SOFTWARE DEVELOPMENT PROCESS MODELS
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.
Regardless of the process model chosen, all the four activities coexist simultaneously at some level of detail.
Problem solving loop with basic four activities, i.e., problem analysis, problem definition, technical development and solution integration.
23
The Linear Models
analysis design code test
System/informationengineering
24
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.
It suggests a systematic, sequential approach to s/w development.
(1) The waterfall model
25
Outline design
Review
Maintenance
Feasibility Study
System Specification
Detailed Design
System Development
Testing & Integration
Implementation
Req. Document
Project Plan
Feasibility
Report
System
Design
Document
Det Design
Document
Programs
Test Plans,
Test Reports
And Manuals Installation
Report
Review
Reports Supplements
Work Tasks &Work Products
25
26
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.
27
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.
(2) Prototyping
Instead of freezing the requirements before design, coding can proceed, a throwaway prototype is built to help understand the requirements.
28
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.
Prototyping…..
29
Disadvantages: The only drawback seems the duplication of efforts and cost
involved in build-twice approach.
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.
Requirements AnalysisDesignCodeTest
Justifications:
Design Code Test
30
Problems to be tackled by Prototyping
Customer’s misconception (req-completion/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
31
high-speed RAD is achieved by using a component-based project construction approach.
Rapid application development (RAD) is a linear sequential S/W development process model that emphasizes on extremely short development cycle.
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).
(3) RAD Model
businessmodeling
datamodeling
processmodeling
applicationgeneration
testing&
turnover
businessmodeling
datamodeling
processmodeling
applicationgeneration
testing&
turnover
businessmodeling
datamodeling
processmodeling
applicationgeneration
testing&
turnover
team #1
team #2team #3
60 - 90 days
32
1. Business Modeling (Business Processes)
• What information is generated?
• Who generates it?
• Where does the information go?
• Who processes it?
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.
Information flows among business functions is modeled such that answers the questions:
RAD Phases (1)
33
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.
RAD Phases (2)
34
5. Testing and Turnover
(2) New components must be tested and all interfaces must be fully exercised. Optimally,
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.
(1) Re-use releases from testing, as such components, are already tested.
(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)
RAD Phases (3)
35
OR Iterative Enhancement Model
1. Solves the problem of 3rd limitation of the waterfall model.
4. Applies linear sequences in a staggered fashion as time progresses.
3. At each step, extensions and design modifications can be made .
2. Basic idea: software should be developed in increments; each increment adding some functionality until the full system is implemented.
(4) The Incremental Model
36
analysis design code testincrement 2 delivery of 2nd increment
3rd incrementdelivery ofanalysis design code testincrement 3
increment 1
delivery of 1st incrementAnalysis Design Code Test
delivery of
analysis design code testincrement n
nth increment
37
Advantages1. Major advantage: it can result in better testing since testing
each increment is likely to be easier than testing the entire system.
2. Similar to prototype each increment provides feed back which is useful for determining further/final requirements of the system.
odel 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.
38
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.
(5) Spiral Model
39
(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, simulation-oriented, or some other approach.
40
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.
41
Agile Development2001: 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 toolWorking software over comprehensive documentationCustomer collaboration over contract negotiationResponding 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.
42
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
43
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.
44
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
45
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)