Speaking Notes

PADM 5500

March 25, 2010

Dr. Neubauer

WHERE WE ARE

We are in chapter 8 of both textbooks this evening.

Final examination for all students is April 22.

Assume that the social network model represents a pattern of communications (information flow) in an organization and that all members of the organization at least occasionally make relatively important decisions.

How significant would be the departure of "O" from the organization? Why?

__________________________________________________________

How significant would be the departure of "C" from the organization? Why?

__________________________________________________________

How significant would be the departure of "W" from the organization? Why?

__________________________________________________________

How significant would be the departure of "F" from the organization? Why?

__________________________________________________________

As a general manager, if someone proposes that the purchase of an upgraded computer system be made possible by "getting rid of" members F, G, and H, how would you respond? In other words, is the substitution of human relationships by the addition of INFORMATION TECHNOLOGY RESOURCES a complete substitution? Why or why not?

Stair and Reynolds, Chapter 8 – Systems Development

It is often not possible for an organization to buy the software it needs OFF THE SHELF and going with an ERP is either not desired or not possible.

There are two major ways for an organization to obtain customized software for its needs.

• Hire consultants to create the new software.

• Have in-house programmers create the new software.

There are potential problems either way.

• You may not want to share information and data with consultants.

• You may not want to enter into a long-term working relationship with consultants.

• You may not have the necessary programming expertise on payroll.

• You may not have the budget or the long-term need to add additional programmers on payroll.

EITHER WAY, you and some of your fellow employees are likely to become involved in the ANALYSIS necessary to build a new software application.

If this is a major project, be sure your have a qualified PROJECT MANAGER. This person probably has a programming background and also has the skills to participate in BOTH ANALYSIS AND DESIGN and to manage the project.

Get some "real" END USERS involved. There are at least two good reasons to include end users.

Have a DEVELOPMENT METHODOLOGY for the entire SOFTWARE DEVELOPMENT LIFECYCLE (SDLC).

The SDLC lasts a long as the resulting software if being used. It may take 12 months or more to do the ANALYSIS, DESIGN, IMPLEMENTATION, TESTING, AND DELOYMENT.

One approach is called the WATERFALL METHODOLOGY. The "spirit" of this approach is, "no going back." The major problem is that it is not agile enough and it delays testing until all the code is written, which is VERY RISKY.

IDENTIFICATION OF A NEED

ANALYSIS OF THE NEEDS

DESIGN OF THE SOLUTION

IMPLEMENTATION (WRITING CODE)

TESTING

DEPLOYMENT

MAINTENANCE

MAINTENANCE includes "bug fixes" and addition of features as it becomes necessary to add features. MAINTENANCE IS THE MOST COSTLY PART OF IT!

There are two major problems associated with the actual use of this approach to the SDLC.

1) During a long project the needs of the organization are changing. It is not acceptable to be unable to accept CHANGE ORDERS until after deployment of the new system.

2) It is VERY RISKY to write all the source code before beginning to test it.

3) Also, you may have programmers sitting around doing nothing because they must wait until others do their part first.

Representation of the Iterative-Incremental Methodology

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

This is the MORE MODERN and BETTER approach and is possible in large part because of the OBJECT-ORIENTED programming paradigm.

PROGRESS is measured by the completion of PHASES which are broken down into multiple INTERATIONS. There is a MILESTONE at the completion of every PHRASE.

At the end of every iteration you should REFACTOR all the artifacts of the project.

Your development team can be doing multiple kinds of work at the same time. It is not necessary to finish one kind of work before going forward to the next.

You can accommodate (reasonable) CHANGE REQUESTS while still in development.

You start writing code and testing code quite early along the way.

You can begin to deploy in BETA while still completing the programming and testing.

ON THE FINAL EXAM I will ask you to interpret what Core Process Workflows are being done in which project Phases.

The spirit of the Iterative-Incremental approach is WE CAN DO MORE THAN ONE THING AT A TIME. At the end of every phase you REFACTOR everything to be sure you are ready to go forward. Refactoring is basically "getting your ducks in a row" so you can move forward to the next phase of the project.

Things to notice about the iterative-incremental model of the SDLC:

• Testing begins "early and often." As soon as there is code written it is being tested. It is the MODULAR nature of object-oriented programming that makes this possible.
• Analysis and design are combined activities and continue well into the construction phase.
• Deployment begins while code is still being written! This is sometimes called Beta testing. This may not be a good idea. Make sure you and the project manager understand each other in this regard.
• This approach may look sloppy but it is not. It requires AN EXPERIENCED SOFTWARE PROJECT MANAGER. If you have such a person, treat him or her well. They are not easy to find and can make a lot more money in the private sector.

Joint Application Development (JAD)

http://en.wikipedia.org/wiki/Joint_application_design

Rapid Application Development (RAD)

http://en.wikipedia.org/wiki/Rapid_application_development

Iterative Development

http://en.wikipedia.org/wiki/Iterative_and_incremental_development

Software Prototyping

http://en.wikipedia.org/wiki/Software_prototyping

The Iterative-incremental model of the SDLC described above is an example of iterative development. You may also hear reference to the spiral model, which is basically the same idea.

JAD and RAD refer to getting all major stakeholders into the same room at the same time and using a computer and projector to model the new system and make sure everyone is "on the same page." Hopefully, this saves time and avoids misunderstandings. It is good to start with Use Case models and work on from there.

Prototyping refers to projecting screens of the new system and designing the INTERFACE together in a JAD/RAD session. The important point is that THE PROTOTYPE IS NOT THE REAL THING. It is "just a pretty interface." All the real work has been stubbed out. It may look like the real thing. It may even appear to FUNCTION like the real thing. BUT IT IS NOT. The risk is that an inexperienced person may get the idea that "we are almost there." I think the prototype should be a THROW AWAY PROTOTYPE. In other words, all the REAL WORK comes later. The prototype is just for TALKING (AGREEMENT) PURPOSES. The code should not be considered application source code.

CHAPTER 8 OF "POWERING UP"

This chapter is about PROCUREMENT and creating a REQUEST FOR PROPOSALS (RFP).

This is likely to be necessary if the organization is small and does not have a staff of professional programmers.

Basically, you do the ANALYSIS in house and then write up an RFP and put it out for bids. The RFP is basically the SPECIFICATIONS and when you selected a vender (consultant) to do the work they do the DESIGN and IMPLEMENTATION and so forth for your agency.

If the RFP is not well thought out the bids may not reflect an understanding of what you really need. Venders can spend many thousands of dollars understanding the RFP and figuring out what it will cost to produce. BE NICE TO THEM!

Usually, there is a list of approved venders and they are the only ones eligible to bid. Otherwise, you would be spending a lot of time "checking out" companies you have never heard of before. Venders, of course, work hard to "get on the list" in order to be eligible to get the contracts.

Notice that this whole process tends to assume THE WATERFALL METHODOLOGY when in fact the better approach is an iterative-incremental model in which analysis and design are mixed.

Realize that when you have major software built by consultants you are ENTERING A LONG-TERM RELATIONSHIP with them that may last MANY YEARS. You want the source code in case they become no longer available to fix bugs and add features.

Contract management is hard. Managing a software development contract is harder.

Some people recommend getting a consultant to manage such contracts. I think ultimately that "someone who really works here" needs to really know what is going on. I am leery of the idea of contracting out the oversight function.