SYSTEMS ANALYSIS project

daven9947

02_SystemsAnalysis-Fall2019-Week21.pdf

Home >Information Systems homework help >SYSTEMS ANALYSIS project

ISMM1-UC 752: SYSTEMS ANALYSIS

Fall 2019 Instructor: Dr. Antonios Saravanos

Assigned Reading: The Mythical Man Month

The Book (1)

1. The Tar Pit 2. The Mythical Man-Month 3. The Surgical Team 4. Aristocracy, Democracy, and System Design 5. The Second-System Effect 6. Passing the Word 7. Why Did the Tower of Babel Fail? 8. Calling the Shot 9. Ten Pounds in a Five-Pound Sack 10. The Documentary Hypothesis 11. Plan to Throw One Away 12. Sharp Tools

The Book (2)

13. The Whole and the Parts 14. Hatching a Catastrophe 15. The Other Face 16. No Silver Bullet – Essence and Accident in

Software Engineering 17. “No Silver Bullet” Refired 18. Propositions of The Mythical Man-Month: True or

False? 19. The Mythical Man-Month after 20 years 20. Fifty Years of Wonder, Excitement and Joy

(Epilogue)

The Tar Pit (1)

• Large-system programming is a tar pit in the last decade.

• The programming systems product:

A Program

A Programming

Product

A Programming

System

A Programming

System Product

The Tar Pit (2)

A Program

A Programming Product: •can be run, tested, repaired and extended by anybody •general enough •well documented

A Programming System:

•collection of interacting programs •precisely defined interfaces between individual programs •comply with resource limitations •all combinations tested

A Programming System Product:

both Programming System and Programming Product

The Tar Pit (3)

• The joys of the craft: – Making things – Making things that are useful to others – The fascination of fashioning complex puzzle-like

objects – Always learning – Such a tractable medium

• The woes of the craft: – Adjusting to the requirement of perfection – Other people tell you what to do – Worse: must use others’ programs!

The Tar Pit (4)

• The woes of the craft (cont.): – Bugs!!! – Bugs get harder as testing progresses – The product gets obsolete upon or even before

completion

The Mythical Man-Month (1)

• Most software projects are late. Why? – Assumption that all will go well led the schedule plan – Confuse effort with progress: men and months are NOT

interchangeable! – Software managers tend to please their managers and

because of uncertainty of programmers’ time estimates, plan the schedule poorly [as a discipline we lack estimating data].

– Poor monitoring of project progress – Natural response to schedule slippage is adding

manpower, which makes matters worse.

The Mythical Man-Month (2)

• Optimism: – All programmers are optimists, believing in happy

endings and fairy god-mothers. – Because programming tasks are usually chained end-to-

end, the probability that each will go well is very small. • Man-month:

– Cost vary as a product: men · months. – Progress does not: communication overhead! – Overhead: intercommunication and training.

Different projects types:

Men

M on th

s Perfectly partitionable task

Men

M on th

Unpartitionable task

Men

M on th

Partitionable task requiring communicationTask with complex interrelationships

Men

M on th

The Mythical Man-Month (4)

• Proposes a successful rule of thumb: – 1/3 planning – 1/6 coding – 1/4 component test and early system test – 1/4 system test, all components in hand

• Gutless estimating, or: an omelette example • Regenerative schedule disaster:

– An example – Brook’s Law: Adding manpower to a late software

project makes it later.

Review

Waterfall Model

What year did Royce publish his paper on the Waterfall model?

1970

How many steps are there in the Waterfall model?

How many times should one go through the Waterfall process according to Royce?

Why 2?

• So what are some other perspectives of Royce’s the waterfall model?

According to Systems Analysis and Design with UML v2.0

Planning Phase • The planning phase is the fundamental process

of understanding why an information system should be built and determining how the project team will go about building it.

Analysis • The analysis phase answers who will use the

system, what the system will do, and where and when it will be used. During this phase, the project team investigates any current system(s), identifies opportunities for improvement, and develops a concept for the new system. The phase has three steps: 1) analysis strategy; 2) requirements gathering; the development of the system proposal.

Design • The design phase decides how the system will

operate, in terms of the hardware, software and network infrastructure; the user interface, forms and reports; and the specific programs, databases, and files that will be needed.

Implementation • The final phase of the SDLC is the

implementation phase, during which the system is actually built (or purchased, in the case of a packaged software design). This phase usually gets the most attention as it is usually the longest and most expensive phase of the development process. It is usually comprised of the following steps: 1) systems construction; 2) installation; 3) establishment of a support plan.

Waterfall Model According to the BCS

• Also known as the once-through approach

• Best for projects where requirements are known up front

Source: Project Management for IT-Related Projects (p. 16)

Is Waterfall a Realistic Approach? • Alistair Cockburn: In waterfall

development, you do “requirements” only once; then you do “design” only once; then you do “programming” only once (ha! ha! fooled you – of course you do the programming over and over and over, but don’t tell your PM that!); you “test” only once (ha! ha! of course not! – but that’s the theory); you “integrate” only once; you “deliver” only once (that part may be true).

Problems with Waterfall Approach • Feedback ignored, milestones lock in design

specs even when conditions change • Limited user involvement (only in requirements

phase) • Too much focus on milestone deadlines of

SDLC phases to the detriment of sound development practices

Are there other approaches? What is Frederick Brook’s approach???

Frederick Brook’s approach • Planning • Coding • Component Test and Early System Test • System Test, All Components in Hand

Do we know how much time we should invest on each of these elements?

Frederick Brook’s approach • 1/3 Planning • 1/6 Coding • 1/4 Component Test and Early System Test • 1/4 System Test, All Components in Hand

Are there other approaches? Well according to our textbook there are three broad categories… • Structured

– Waterfall – Parallel

• RAD – Phased – Prototyping – Throwaway Prototyping

• Agile – Extreme

Parallel Development Methodology

What does Brook’s Think of Parallel?

Source: http://home.ubalt.edu/abento/737/projmgt.html

Why?

Why? Communication

E = n(n – I) / 2

Are there other approaches? Well according to our textbook there are three broad categories… • Structured

– Waterfall – Parallel

• RAD – Phased – Prototyping – Throwaway Prototyping

• Agile – Extreme

Rapid Application Development (RAD)

• Decreases design and implementation time

• Involves: extensive user involvement, prototyping, integrated CASE tools, code generators

• More focus on user interface and system function, less on detailed business analysis and system performance

Rapid Application Development (RAD) Lifecycle

Phased Development Methodology

Prototyping

Throwaway Prototyping

Boehm Spiral Model

Extreme Programming

Comparing Methodologies

Quick Exercise

Incremental Model

• Development and delivery of functionality occurs in increments

• Works well when requirements are known beforehand

• Projects are broken down into sub- projects

Source: Project Management for IT-Related Projects (p. 18)

Incremental Cycle

Incremental Model

Iterative Model

• Ideal for situations where not all requirements are known up front

• Need for development to begin as soon as possible

Source: Project Management for IT-Related Projects (p. 19) 56

Iterative Cycle

Iterative Model

Incremental vs. Iterative

• Incremental fundamentally means add onto. Incremental development helps you improve your process.

• Iterative fundamentally means re- do. Iterative development helps you improve your product.

• Is iterative and incremental the same thing?

Incremental vs. Iterative

Source: http://www.applitude.se/images/inc_vs_ite.png

Iterative and Incremental Combined

Alistair Cockburn • What’s Alistair’s take on Iterative vs. Incremental?

Incremental vs. Iterative • in incremental development, you do each of those

activities multiple times … that is, you go around the requirements – design – programming – testing – integration – delivery cycle multiple times. You “iterate” through that cycle multiple times. (“iterate” – get it? sigh…)

• in iterative development, you also do each of those activities multiple times … you go around the requirements – design – programming – testing – integration – delivery cycle multiple times. You “iterate” through that cycle multiple times. By Gummy! Both of those are “iterative” development! WOW!

Incremental vs. Iterative (cont’d)

• Of course, the $200,000 question is, do you repeat the cycle

• “on the same part of the system you just got done with” or

• “on a new part of the system”???  How you answer that question yields very different results on what happens next on your project.

Quick Exercise

Specialization

Computer-aided software engineering (CASE) tools

• CASE tools are productivity tools for systems analysts that have been created explicitly to improve their routine work through the use of automated support

Reasons for Using Case Tools

• Reasons for using CASE tools – Increasing analyst productivity – Improving analyst-user communication – Integrating life cycle activities

Case Tools

• Classic CASE tools - established software development support tools (e.g. interactive debuggers, compilers, etc.)

• Real CASE tools - can be separated into three different categories, depending on where in the development process they are most involved in: – Upper - support analysis and design phases – Lower - support coding phase – Integrated - also known as I-CASE support analysis, design and

coding phases

Case Tool Classifications

• Upper CASE tools perform analysis and design.

• Lower CASE tools generate programs from CASE design.

Upper CASE Tools

• Create and modify the system design. • Help in modeling organizational

requirements and defining system boundaries.

Lower CASE Tools

• Lower CASE tools generate computer source code from the CASE design.

• Source code is usually generated in several languages.

• Decreases maintenance time • Generates error-free code

Computer-Aided Software Engineering (CASE) Tools

• Diagramming tools enable graphical representation.

• Computer displays and report generators help prototype how systems “look and feel”.

• IBM’s Rational products are the best known CASE tools.

Computer-Aided Software Engineering (CASE) Tools

• Analysis tools automatically check for consistency in diagrams, forms, and reports.

• A central repository provides integrated storage of diagrams, reports, and project management specifications.

Computer-Aided Software Engineering (CASE) Tools (Cont.)

• Documentation generators standardize technical and user documentation.

• Code generators enable automatic generation of programs and database code directly from design documents, diagrams, forms, and reports.

CASE Tools

FIGURE 1-11 Screen shot of ArgoUML, an open source CASE tool

(Source: http://argouml.tigris.org/)

CASE Tools