Systems Analysis and Design

Book: Systems Analysis and Design 6e Kendell & Kendall

Chapter 3 Determing Feasability and Managing Analysis and Design Activities

Project Initiation
Can come from many different sources. They come because people see problems that need fixing and people see opportunities for improvement in the way things are done.
Problems in the Organization
It is wise not to think of problems as that, but as situations in which objectives can get help in being met. Many of these problems will be noticed when feedback is given in the system. The feedback can often come from outside the organization.
Selection of Projects
Projects should not be chosen for political purposes, or to gain power in the organization. Remember that any change in one part of an organization will affect other parts of the organization. Criteria for taking on a project should be as follows.
Backing from management - the people that pay the bills need to support the project
Appropriate timing of project - does the organization have the time to install the new system.
Possibility of improving the reaching of goals - it should not deter from reaching the goals, it should help reach them.
Do you and/or the organization have the skills to do the project?
Is it worthy compared to other projects?
Determining Feasibility
Not a full blown study but a quick look to see if organization should go on.
Defining Objectives
Projects should be taken on if they can cause improvements. Some standards that you can look at are some things that will speed up or streamlining a process, combining processes, reducing errors, reducing redundant storage or output and improving integration of systems. An analyst should take time to make a FIG (Feasibility Impact Grid) to see how the changes will affect not only the Process Objectives but the corporate objectives as well. The analyst should look to see that a project is necessary and not just another way to spend money on bells and whistles for the purpose of having the bells and whistles.
Determining Resources
In the process of determining if company has the resources they should look at three areas of feasibility: technical, economic and operational.
In technical feasibility we look to see if the technology is currently available is available to purchase.. Remember that patching an old system may wind up costing more than doing a new system.
In looking at economic feasibility, the cost of doing a full study is analyzed as well as the cost to the company to develop what is needed.
Do users want a new system or are they tied to the old system? This is the operational feasibility study.
Judging Feasibility
The preliminary study should cover all three of these aspects. Projects that pass the test should go on to the next stage and is not a commitment from management that they will be done.
Activity Planning and Control
Estimating Time Required
A systems analyst should break down the project into three parts: analysis, design and implementation. Each of these gets broken down further. Analysis - data gathering, data flow and decision analysis and proposal presentation. Design - data entry design, input and output design, and data organization. Implementation - implementation and evaluation. These steps can be broken down into further jobs as well. A hard part of the work can be planning how much time each one of these tasks is going to take.
Using Gantt Charts for Project Scheduling
A Gantt chart is a two-dimensional chart that shows activities on a horizontal axis. The horizontal axis represents the time frame of the project. Tasks are listed in boxes to represent the time frame that they will take and when they will take place. It has as an advantage, simplicity.
Using PERT Diagrams
Program (another word for a project) Evaluation and Review Techniques (PERT) Diagrams are laid out as circles that have interconnecting lines. These lines show what tasks must be done before the next connecting circle can be done. In using Gantt charts it is unclear sometimes if a task needs to wait for another task before it can be done or if it just happens to end when another task begins. The circles are usually numbered in two digits to show the left to right progression of a task. By adding up the largest amounts of days in the progressions it is possible to determine how long it will take to do a job. This can be referred to as the critical path.
Computer-Based Project Scheduling
Computer software has made these charts easier to do. One major software that does this is Microsoft Project.
Timeboxing
This involves setting a due date for the project and what ever is not implemented will be left off for the time being. Another method used is PIM software and people's to do lists.
Managing Analysis and Design Activities
Communication Strategies for Managing Teams
Teams tend to have two leaders, one to accomplish the task at hand and another that shows concern for the socio-emotional needs of the members. Feedback must be a constant thing if the members of a group are to avoid friction. Groups form their own way of doing things, called norms. Most norms do not pass from one group to another or may even change over time. Some norms, though they have existed for a while may be counter-productive.
Setting Project Productivity Goals
Any goals that affect the team need to be agreed upon by the team.
Motivating Project Team Members
Goal setting is an excellent way to motivate people.
Managing Projects Using COTS Software
The use of commercial off-the-shelf (COTS) software can allow for quick implementation if you can find ones that fit your needs easily or can be modified by the use of templates etc. It is wise to test these out though, because installing one COTS may break another.
Managing Ecommerce Projects
Ecommerce projects can cause problems because the information is scattered over many different departments and this can cause territorial battles over who owns the information. Ecommerce teams tend to need people with more and varied skills as well. Because of linking to outside world via the Internet, security becomes a major importance.
Avoiding Project Failures
Avoid the unrealistic dates problem when ever possible. Do not buy into the myth that more people will get the job done quicker. And if needed get outside help. These all will prevent projects from failing. If a group decides to take on a project it represents them if it is completed or not.
Extreme Programming Projects
XP is a system development approach taking good development practices to an extreme. Four variables that a developer can control are time, cost, quality and scope. They must balance out with the coding, testing, designing and listening activities of project development. By controlling the amount of each of these, a project is kept in balance. If we know what the time, cost and quality are, we can adjust for the scope as needed.
Extreme Programming Resource Trade-Offs
Time - you need enough time to complete the project. Running short on time may not be a bad thing if you can implement enough of the project to keep customer happy. Try not to extend deadline, the XP approach focuses on finish on time.
Cost - Increasing cost does not always add to the project, especially hiring more people. More people lead to more confusion and overtime leads to tired workers. It is possible to purchase better tools to do the job, but all projects should stay under the budget they have set up.
Quality - Internal quality (bug checking and the like) cannot be sacrificed but it is possible to let external quality to slide. In order to meet deadlines, some bugs may have to be accepted by the customer or the user interface may not be just right.
Scope - What the customer wants may have to be delayed for another version of the software in order to meet deadlines.
Extreme Programming Core Practices and Roles
Four XP core practices
1. Short release - get it out quick and on time, even if features missing.
2. 40 hour work week - keep your people rested and they work better
3. Onsite customer - customer should be heavily involved in the development team
4. Pair programming - team programmers together can work quite well in bouncing ideas back and forth and testing things.

Roles for People
Programmer
Customer - be clear what you want
Tester (sometimes done by programmer but better done separately)
Tracker - tracks progress of how well things are being done and kept on schedule
Coach - keep people motivated
Consultant - help them learn to solve their own problems.
Big Boss confidence in project and keep things flowing

The Planning Game
The metaphor of a game helps how one looks at a project. In any game you want to maximize your potential to help team or self win.

How project risks are handled by XP
Use a fishbone diagram to view the possible problems that could develop in a project and then do not let them happen.
Developmental Process for an XP Project
1. Explore - decide to take the project or not.
2. Planning - Once taken set up time frames.
3. Iterations - testing, feedback and change in repletion until done. Celebrate your progress points
4. Productionizing final features and release
5. Maintenance - keep running smoothly, add some features.