Speaking Notes

PADM 5500

April 1, 2010

Dr. Neubauer

WHERE WE ARE

We are still in Chapter 8 of Stair and Reynolds. We will get into Chapter 9 of Barrett and Greene next week.

REVIEW

• The waterfall approach is simple but not very practical today. It was a better match for slower times and with procedural programming.
• The iterative-incremental (spiral) approach is more complicated for a project manager to manage but is a better match for today's dynamic environments and with object-oriented programming techniques.

The major limitation of the waterfall methodology are:

• It does not accommodate changes well during the project.
• It apparently delays testing until all the source code has been written.

The newer iterative-incremental approach is often used in conjunction with RAPID PROTOTYPING. The two possible drawbacks of rapid prototyping are:

• That some of the prototyping code might get included in the real source code.
• That someone may mistake the prototype for a nearly complete real application.

THE POINT IS that general managers need to be aware of how specialized software is produced else decisions that they should make are likely to be made by (well intentioned) technical experts (i.e. programmers). Software is too important for managers to not be involved and understand at least the basics.

ANALYSIS involves understanding the needs of the organization. DESIGN involves (the programmers) figuring out how to actually create the source code of the application to become the solution to the "business" problem. In "waterfall" these are sequential. In "iterative-incremental" they are acknowledge to overlap.

NEW MATERIAL THIS EVENING

• "Use cases" and how use case diagrams contribute to analysis.
• How use case diagrams feed into prototyping the application.
• Major strategies for the DEPLOYMENT of a new application in the organization.
• A bit about outsourcing and contract management.

USE CASE ANALYSIS

WHO (what kinds of users) are going to use the new system and WHAT does the system need to allow them to do?

An ACTOR is a kind of user -- technically, a class of user.

A USE CASE is a significant unit of functionality. (Logging in is not a use case because no one uses a system because they want to log in.)

This use case diagram includes one actor (citizen), one use case (identify voting location) and one association (the line between).

CLASS EXERCISE: create a use case diagram for a bank's ATM system and include the following actors: customer, teller, maintenance person.

Notice that a use case diagram IS NOT A FLOW CHART. It simply answers the questions:

• What kinds of users will use this application?
• What will they need the system to do for them?

It is useful for SCREEN DESIGN, which is the essence of APPLICATION PROTOTYPING. Remember, a prototype is, "just a pretty interface."

Figure 1: Student course selection and advisement system use case diagram

1) Identify the actors: _________________________________________________

2) Identify the primary use cases that must be available to registrars.

__________________________________________________________________

3) According to the use case diagram above, who (what classes of actors) should be able to view holds?

4) What is the value of a use case diagram to administrators and business analysts?

5) What is the value of a use case diagram to programmers and software project managers?

Figure 2: Microsoft Visual Studio integrated development environment application

6) What do objects "have?" What are examples of programming objects?

7) How hard is it to create a common object using a visual integrated development environment application like Microsoft Visual Studio?

8) Draw a prototype of the application's log in form (screen). In other words, what objects are necessary and how should they be arranged on the form? What needs to happen when someone presses the button?

9) Based on the use case diagram on a previous page, modify the text properties of the button objects above to reflect the primary use cases of registrars.

Stair and Reynolds, Chapter 8 – Systems Development

Representation of the Iterative-Incremental Methodology

source: Rational Software Corporation (now part of IBM Corporation)

This is an important chapter to me. I think it gets at the heart of what general administrations need to understand about systems analysis and development.

• The meaning of the SDLC and the two major methods of approaching the SDLC.
• The benefits of the iterative-incremental method as compared to the waterfall method.
• The "spirit" of the iterative-incremental approach.
• The meaning of phases and core-process workflows.
• The meaning of refactoring all the project artifacts at the end of each phase.
• The fact that the iterative-incremental approach requires use of OBJECT ORIENTED PROGRAMMING TECHNIQUES which are MODULAR in nature and facilitate early testing.
• THE DIFFERENT WAYS TO APPROACH DEPLOYMENT.
• The meaning of maintenance and the importance of TECHNICAL DOCUMENTATION to the ability to modify source code.
• The meaning of JAD and RAD and the value of them.
• The meaning of PROTOTYPING and the risk of misusing the code or misunderstanding what a prototype is.
• The importance of having END USERS in the room.
• The fact that ANALYSIS and DESIGN get kind of blended together when using the iterative-incremental approach.
• The fact that the RFP process forces an artificial separation between analysis and design by requiring that the specs be written prior to the selection of the consultant (vender).
• Fuzzy (unclear) specifications are not good. It is hard to document all your assumptions. It is hard to avoid the, "BUT YOU DID NOT SAY THAT!"
• The fact that contacting out for a major software application may be the initiation of A LONG TERM RELATIONSHIP because the consultants who write the code may be best able to MAINTAIN the code for years to come.
• YOU WANT THE SOURCE CODE and it will cost you something to have it. But having it frees your agency from the consultants who wrote it.
• The approved list of venders prevents the agency from having to investigate venders they have never heard of before.
• DO RIGHT by the venders who are preparing to bid. Otherwise you may get a LOW BALL bid from a vender who does not really understand the project and you may feel POLITICAL PRESSURE to accept the low bid.
• DON'T ASSUME THIS IS EASY. Millions of dollars have been sunk into failed IT projects.
• YOU CAN'T DELEGATE EVERYING AWAY. SOMEBODY WHO WORKS "HERE" HAS TO "HAVE A CLUE."

There are two major models of DEPLOYMENT. One is ABRUPT CUTOVER. The other is some form of PHASED DEPLOYMENT.

• ABRUPT CUTOVER is high risk but "cleaner."
• PHASED DEPLOYMENT is safer but may be confusing during the transition and may require RUNNING PARALLEL SYSTEMS for a while, which may not be feasible.