1. IT2005 System Analysis & Design
Week 5 & 6 -Major Components of Systems Development

2. Major components of system development
Methodology
Modeling Methods or Techniques
Tools

3. Methodology
A very formal and accurate system development process that defines a set of
Activities
Methods
Best practices
Deliverables
Automated tools
Methodology
Methods
Or Techniques
Tools

4. Methodology.. Provides the framework Has a predefined set of steps
Ensures that systems are built in the most effective way
Eg:
 SSADM (structured methodologies)
STRADIS (Structured Analysis, Design and Implementation of Information Systems)
YSM (Yourdon Systems Method)

5. Methodology
Modeling Methods
Or Techniques
Eg: Class diagram,
usecase diagram
Tools
Eg: Rational rose

6. Modeling method A set of techniques used to implement a Methodology.
Data Flow Diagrams
A process model
Depict the flow of data through a system and the work performed by the system
Entity Relationship Diagrams
A data model
Depict data in terms of entities and relationships described by the data
Consists of several notations
Structure Charts etc.

7. Tools
Tools are Software systems and they assist analysts and designers to build information systems.
General Aim :
Decrease the human effort required to develop the software
Increase the quality of software
Tools will support methodologies but will not replace system analysts.
e.g. Easy Case, Rational Rose

8. Underlying Principles for System Development methodology
P1: Get the system users involved P2: Use a problem-solving approach P3: Establish phases and activities. P4 : Document through out Development P5: Establish standards P6 :Manage the process and Projects P7:Justify systems as Capital Investments. P8:Don’t be afraid to cancel or revise scope. P9:Divide and conquer P10: Design systems for growth and change.

9. What is a Software Process?
A set of ordered tasks involving activities , constraints and resources that produce a software system.

10. Software process models
Waterfall model
Prototyping models
Evolutionary models
The spiral model
Formal development
Incremental development
Rapid Application Development
Unified Process
Agile Process
Extreme Programming (XP)

11. The Waterfall model
Separate and distinct phases of specification and development
A linear sequential model
requirements
analysis & spec
software
design
coding
testing
Maintenance

12. Software Life Cycle Models
Waterfall lifecycle

13. Waterfall Strengths Easy to understand, easy to use
Provides structure to inexperienced staff
Milestones are well understood
Sets requirements stability
Good for management control (plan, staff, track)
Works well when quality is more important than cost or schedule

14. Problems with Waterfall Development Approach

15. Problems with Waterfall Development Approach……
There are several problems with this approach.
It has a rigid design
Inflexible
It has a top-down procedure
One phase must be completed before the next phase starts
No phase can be repeated
Time consuming
There are several criticisms of the Waterfall development approach

16. Modified Waterfall Development Approach
Uses the same phases as the pure waterfall development approach.
Allow some of the stages to overlap, such as the requirements stage and the design stage.
Another common modification is to incorporate prototyping into the requirements phases.
Overlapping stages make it possible to integrate feedback from the design phase into the requirements.
Progress is more difficult to track.

17. When to use the Waterfall Model
The linear cycles are usually best suited to problems which are well understood and highly structured.
Attractive for large problems.
Projects which have clear and stable requirements.

18. Prototyping
It is very difficult for end-users to anticipate how they will use new software systems to support their work. If the system is large and complex, it is probably impossible to make this assessment before the system is built and put into use.
A prototype ( a small version of the system) can be used to clear the vague requirements. A prototype should be evaluated with the user participation.
There are two types of Prototyping techniques
* Throw-away Prototyping
* Evolutionary Prototyping
Vague-not clear

19. Throw-away and Evolutionary Prototyping
Executable prototype +
System specification
Throw-away
prototyping
Outline
Requirements
Evolutionary
prototyping
Delivered system

20. Throw-away Prototyping
specify system
establish outline specification
components
evaluate prototype
develop prototype
validate system
design and implement system
Delivered
software
system

21. Throw-away Prototyping
The objective is to understand the system requirements clearly. Starts with poorly understood requirements. Once the requirements are cleared, the system will be developed from the beginning.
This model is suitable if the requirements are vague but stable.

22. Some problems with Throw-away Prototyping
Important features may have been left out of the prototype to simplify rapid implementation. In fact, it may not be possible to prototype some of the most important parts of the system such as safety-critical functions.
An implementation has no legal standing as a contract between customer and contractor.
Non-functional requirements such as those concerning reliability, robustness and safety cannot be adequately tested in a prototype implementation.

23. Evolutionary Prototyping
Develop abstract
specification
Build prototype
system
Evaluate prototype
system NO
System
Adequate?
YES
Deliver
system

24. Structured Evolutionary Prototyping Strengths
Customers can “see” the system requirements as they are being gathered
Developers learn from customers
A more accurate end product
Unexpected requirements accommodated
Allows for flexible design and development
Interaction with the prototype stimulates awareness of additional needed functionality

25. Prototyping Weaknesses
Prototyping can lead to false expectations.
Prototyping can lead to poorly designed systems.
Overall maintainability may be overlooked
The customer may want the prototype delivered.
Process may continue forever (scope creep)
Continual change tends to corrupt the structure of the prototype system. Maintenance is therefore likely to be difficult and costly.

26. Evolutionary Prototyping (continued)
Disadvantages
* Prototype usually evolve so quickly that it is not cost- effective to
produce greater deal of documentation
* Continual change tends to corrupt the structure of the prototype
system. Maintenance is therefore likely to be difficult and costly.
* It is not clear how the range of skills which is normal in software
engineering teams can be used effectively for this mode of
development.
* Languages which are good for prototyping not always best for final
product.

27. The RAD Model Team 3 Team 2 Team 1 60 –90 days Business modeling
Data
modeling
Data
modeling
Data
modeling
Process
modeling
Process
modeling
Application
generation
Process
modeling
Application
generation
Application
generation
Testing &
turnover
Testing &
turnover
Testing &
turnover
60 –90 days

28. Processes in the RAD model
Business modelling - The information flow in a business system considering its functionality.
Data Modelling - The information flow defined as part of the business modelling phase is refined into a set of data objects that are needed to support the business
Process Modelling - The data objects defined in the data modelling phase are transformed to achieve the information flow necessary to implement business functions.
Application generation - RAD assumes the use of 4GL or visual tools to generate the system using reusable components.
Testing and turnover
New components must be tested and all interfaces must be fully exercised
Turnover-Pirivatupa

29. Cont. RAD lifecycle Contract Feedback Prototype Development
Requirement
Definition/ Refinement
Design
Cutomer Prototype Review
Feedback
Deployment

30. The RAD model
Rapid Application Development (RAD) is an incremental software development process model that emphasizes an extremely short development cycle.
If requirements are well understood and project scope is constrained, the RAD process enables a development team to create a ‘fully functional system’ within very short time periods (eg. 60 to 90 days)

31. Some problems with the RAD model
RAD requires sufficient human resources to create right number of RAD teams
RAD requires developers and customers who are committed to the rapid-fire activities necessary to get a system completed in a much abbreviated time frame.
If a system cannot be properly modularized, building the components necessary for RAD will be problematic.
RAD is not applicable when technical risks are high.

32. Incremental Model conception architecture deliver 1st Increment
analysis
design
code
test
deliver 2nd Increment
deliver 3rd Increment
structure
feedback

33. Incremental Development
The Incremental development model involves developing the system in an incremental fashion.
The most important part of the system is fist delivered and the other parts of the system are then delivered according to their importance.
Incremental development is more manageable than evolutionary prototyping as the normal software process standards are followed.
Plans and documentation must be produced

34. Iterative Development Approach

35. Iterative Development Approach
Iterative development approach completes the entire IS in successive iterations.
Each iteration does some
analysis
design
construction
Allows versions of usable information to be delivered in regular and shorter time frames.
The iteration process helps to develop a part of the new system and place it into operation as quickly as possible.

36. Spiral model
The spiral model (Boehm, 1988) aims at risk reduction by any means in any phase.
quadrant 1
determine objectives of that phase
alternatives and constraints.
quadrant 2
analyzed form the viewpoint of risk
solutions to minimize these risks are investigated, often using prototyping.
quadrant 3
where the traditional waterfall model phases are put into practice.
Quadrant4
the results of the risk-reduction strategies

37. Spiral model

38. Spiral Quadrant Determine objectives, alternatives and constraints
Objectives: functionality, performance, hardware/software interface, critical success factors, etc.
Alternatives: build, reuse, buy, sub-contract, etc.
Constraints: cost, schedule, interface, etc.

39. Spiral Quadrant Evaluate alternatives, identify and resolve risks
Study alternatives relative to objectives and constraints
Identify risks (lack of experience, new technology, tight schedules, poor process, etc.
Resolve risks (evaluate if money could be lost by continuing system development)

40. Spiral Quadrant Develop next-level product
Typical activates:
Create a design
Review design
Develop code
Inspect code
Test product

41. Spiral Quadrant Plan next phase
Typical activities
Develop project plan
Develop configuration management plan
Develop a test plan
Develop an installation plan

42. Spiral Model Strengths
Provides early indication of insurmountable risks, without much cost
Users see the system early because of rapid prototyping tools
Critical high-risk functions are developed first
The design does not have to be perfect
Users can be closely tied to all lifecycle steps
Early and frequent feedback from users

43. Spiral Model Weaknesses
Time spent for evaluating risks too large for small or low-risk projects
The model is complex
Risk assessment expertise is required
May be hard to define objective, verifiable milestones that indicate readiness to proceed through the next iteration

44. When to use Spiral Model
When creation of a prototype is appropriate
When costs and risk evaluation is important
For medium to high-risk projects
Long-term project commitment unwise because of potential changes to economic priorities
Users are unsure of their needs
Requirements are complex
New product line
Significant changes are expected (research and exploration)

45. V-Shaped SDLC Model
Testing of the product is planned in parallel with a corresponding phase of development

47. V-Shaped Strengths
Emphasize planning for verification and validation of the product in early stages of product development
Each deliverable must be testable
Project management can track progress by milestones
Easy to use

48. V-Shaped Weaknesses Does not easily handle concurrent events
Does not handle iterations or phases
Does not easily handle dynamic changes in requirements
Does not contain risk analysis activities

49. Waterfall vs Agile
Timeboxing

50. RAD: Definition? Many Definitions : same philosophy Definition 1:
A software development process that allows usable systems to be built within a short period (as little as 2-3 months), often with compromises.
It is a generic term with the meaning “speedy development” or “Shorter schedule”

51. RAD
Rapid Application Development (RAD) refers to a type of software development which uses “optimal” planning in favor of rapid prototyping.
The "planning" of software developed using RAD is interleaved with writing the software itself.
The lack of extensive pre-planning generally allows software to be written much faster, and makes it easier to change requirements.

52. RAD lifecycle
RAD compresses the step-by-step development process into an iterative process.
User requirements are refined.
A system is designed.
A prototype is developed.
The prototype is reviewed by end-user.
User provide feedback.
The process is repeated.

53. Review Questions
The following are initial requirements specified by some customers. Identify the most suitable process models for these software projects.
(a) “ I need to develop a simple library system for my school. I know the requirements very well”
(b) “I need to develop a management information system for my organization,. I may use it for all the branches in several location in Sri Lanka. I might use it on the Internet”.
(c ) “ I need to develop a software system to control a space shuttle”