SAD 1 - Assignment 5

University Life Cycle

Considering our university, of course I don’t know life cycle model is used for the university but I think it is specifically designed for the university. In every organization the kind of SLDC to be used is always considered to fit for that certain organization. I think every model is designed to meet the needs of the users on the organization. Here I have defined what is a SLDC or a systems development life cycle.
The systems development life cycle (SDLC) is a conceptual model used in project management that describes the stages involved in an information system development project, from an initial feasibility study through maintenance of the completed application. Various SDLC methodologies have been developed to guide the processes involved, including the waterfall model (which was the original SDLC method); rapid application development (RAD); joint application development (JAD); the fountain model; the spiral model; build and fix; and synchronize-and-stabilize.
Often, several models are combined into some sort of hybrid methodology. Documentation is crucial regardless of the type of model chosen or devised for any application, and is usually done in parallel with the development process. Some methods work better for specific types of projects, but in the final analysis, the most important factor for the success of a project may be how closely the particular plan was followed.

In general, an SDLC methodology follows these steps:
1. If there is an existing system, its deficiencies are identified. This is accomplished by interviewing users and consulting with support personnel.
2. The new system requirements are defined including addressing any deficiencies in the existing system with specific proposals for improvement.
3. The proposed system is designed. Plans are created detailing the hardware, operating systems, programming, and security issues.
4. The new system is developed. The new components and programs must be obtained and installed. Users of the system must be trained in its use, and all aspects of performance must be tested. If necessary, adjustments must be made at this stage.
5. The system is put into use. This can be done in various ways. The new system can phased in, according to application or location, and the old system gradually replaced. In some cases, it may be more cost-effective to shut down the old system and implement the new system all at once.
6. Once the new system is up and running for a while, it should be exhaustively evaluated. Maintenance must be kept up rigorously at all times. Users of the system should be kept up-to-date concerning the latest modifications and procedures.
If you're looking to hire a project manager with a strong software development background, contact me and I'd be happy to discuss your company's project needs and how I can address them.
http://www.mariosalexandrou.com/methodologies/systems-development-life-cycle.asp

System Development Life Cycle

Life Cycle (SDLC) is a conceptual model used in project management that describes the stages involved in an information system development project from an initial feasibility study through maintenance of the completed application. Various SDLC methodologies have been developed to guide the processes involved including the waterfall model (the original SDLC method), rapid application development (RAD), joint application development (JAD), the fountain model and the spiral model. Mostly, several models are combined into some sort of hybrid methodology. Documentation is crucial regardless of the type of model chosen or devised for any application, and is usually done in parallel with the development process. Some methods work better for specific types of projects, but in the final analysis, the most important factor for the success of a project may be how closely particular plan was followed.
The image below is the classic Waterfall model methodology, which is the first SDLC method and it describes the various phases involved in development.

Briefly on different Phases:

Feasibility
The feasibility study is used to determine if the project should get the go-ahead. If the project is to proceed, the feasibility study will produce a project plan and budget estimates for the future stages of development.

Requirement Analysis and Design
Analysis gathers the requirements for the system. This stage includes a detailed study of the business needs of the organization. Options for changing the business process may be considered. Design focuses on high level design like, what programs are needed and how are they going to interact, low-level design (how the individual programs are going to work), interface design (what are the interfaces going to look like) and data design (what data will be required). During these phases, the software's overall structure is defined. Analysis and Design are very crucial in the whole development cycle. Any glitch in the design phase could be very expensive to solve in the later stage of the software development. Much care is taken during this phase. The logical system of the product is developed in this phase.

Implementation
In this phase the designs are translated into code. Computer programs are written using a conventional programming language or an application generator. Programming tools like Compilers, Interpreters, Debuggers are used to generate the code. Different high level programming languages like C, C++, Pascal, Java are used for coding. With respect to the type of application, the right programming language is chosen.

Testing
In this phase the system is tested. Normally programs are written as a series of individual modules, these subject to separate and detailed test. The system is then tested as a whole. The separate modules are brought together and tested as a complete system. The system is tested to ensure that interfaces between modules work (integration testing), the system works on the intended platform and with the expected volume of data (volume testing) and that the system does what the user requires (acceptance/beta testing).

Maintenance
Inevitably the system will need maintenance. Software will definitely undergo change once it is delivered to the customer. There are many reasons for the change. Change could happen because of some unexpected input values into the system. In addition, the changes in the system could directly affect the software operations. The software should be developed to accommodate changes that could happen during the post implementation period.
http://www.startvbdotnet.com/sdlc/sdlc.aspx

Once upon a time, software development consisted of a programmer writing code to solve a problem or automate a procedure. Nowadays, systems are so big and complex that teams of architects, analysts, programmers, testers and users must work together to create the millions of lines of custom-written code that drive our enterprises.
To manage this, a number of system development life cycle (SDLC) models have been created: waterfall, fountain, spiral, build and fix, rapid prototyping, incremental, and synchronize and stabilize.
The oldest of these, and the best known, is the waterfall: a sequence of stages in which the output of each stage becomes the input for the next. These stages can be characterized and divided up in different ways, including the following:
• Project planning, feasibility study: Establishes a high-level view of the intended project and determines its goals.
• Systems analysis, requirements definition: Refines project goals into defined functions and operation of the intended application. Analyzes end-user information needs.
• Systems design: Describes desired features and operations in detail, including screen layouts, business rules, process diagrams, pseudocode and other documentation.
• Implementation: The real code is written here.
• Integration and testing: Brings all the pieces together into a special testing environment, then checks for errors, bugs and interoperability.
• Acceptance, installation, deployment: The final stage of initial development, where the software is put into production and runs actual business.
• Maintenance: What happens during the rest of the software's life: changes, correction, additions, moves to a different computing platform and more. This, the least glamorous and perhaps most important step of all, goes on seemingly forever.

But It Doesn't Work!
The waterfall model is well understood, but it's not as useful as it once was. In a 1991 Information Center Quarterly article, Larry Runge says that SDLC "works very well when we are automating the activities of clerks and accountants. It doesn't work nearly as well, if at all, when building systems for knowledge workers -- people at help desks, experts trying to solve problems, or executives trying to lead their company into the Fortune 100."
Another problem is that the waterfall model assumes that the only role for users is in specifying requirements, and that all requirements can be specified in advance. Unfortunately, requirements grow and change throughout the process and beyond, calling for considerable feedback and iterative consultation. Thus many other SDLC models have been developed.
The fountain model recognizes that although some activities can't start before others -- such as you need a design before you can start coding -- there's a considerable overlap of activities throughout the development cycle.
http://www.computerworld.com/s/article/71151/System_Development_Life_Cycle

The System Development Life Cycle (SDLC) process applies to information system development projects ensuring that all functional and user requirements and agency strategic goals and objectives are met. The SDLC provides a structured and standardized process for all phases of any system development effort. These phases track the development of a system through several development stages from feasibility analysis, system planning and concept development; to acquisition and requirements definition; design; development; integration and testing; deployment and acceptance; though deployment and production; and finally to system retirement.
The Records Management (RM) Profile1 recommends that agencies embed records management requirements in the earliest stages of the SDLC. The following document is a checklist to assist agencies to integrate RM into the SDLC. The checklist identifies certain points in the SDLC process where the agency may propose to establish records management review and approval to ensure that sound RM practices are incorporated into the development of its proposed ITsystems. While the attached SDLC diagram demonstrates these stages in a linear “waterfall” systems development methodology, the checklist can be used with other systems development methodologies as well, such as “spiral,” “parallel,” “rapid application development (RAD)” and
“prototyping” by modifying the checklist to fit the phases of the preferred SDLC method used.
The checklist provides three to five basic questions about records management and recordkeeping for each phase of the SDLC lifecycle process. The checklist questions are intended to begin a more detailed discussion with agency records managers, IT and CPIC staff, and program managers and staff that will help identify recordkeeping requirements in each phase, with a great emphasis on identifying records management requirements at the earliest stages of project planning, initiation and requirements gathering. Because individual agency SDLC processes and policies vary widely, the checklist is not designed to be used as the only
checklist an agency might need, or even a “one size fits all” approach to identifying recordkeeping requirements within an individual agency’s SDLC policies. Rather, the checklist demonstrates a widely used methodology to plan and develop new IT systems that can be used as a model or template that individual agencies can revise or tailor to their own unique SDLC process, IT and systems development policies and procedures to identify their unique records management and recordkeeping requirements. For instance, some agencies use a five-step SDLC process, and others use a ten-step process, and they should revise or modify checklist to meet their specific SDLC policy and business needs.
http://www.archives.gov/records-mgmt/initiatives/sdlc-checklist.pdf

SAD 1 - Assignment 4

Systems Development Models

Before any software is made there is a process to go through to make it work. It passes through phases to make it as faultless as possible for the users. It might go through planning, coding, developing and other steps before one can create a software system work. This now relates to process model. If I were to define it from the word itself it is a flow of steps to organize the building or engineering of a software system. Having a process model help us to strategies what should be done for the system and help create the algorithm of the program.
For a better understanding and for a more concrete definition, here follows the definition of process model from Wikipedia.
“Process models are processes of the same nature that are classified together into a model. Thus, a process model is a description of a process at the type level. Since the process model is at the type level, a process is an instantiation of it. The same process model is used repeatedly for the development of many applications and thus, has many instantiations. One possible use of a process model is to prescribe how things must/should/could be done in contrast to the process itself which is really what happens. A process model is roughly an anticipation of what the process will look like. What the process shall be will be determined during actual system development.”

Software process models represent a sequence of activities or events that symbolize strategies for accomplishing software development. Process models can be used to develop more precise and formalized descriptions of software life cycle activities. Based on my reading software process network represents a multiple interconnected task chains that transform object to what it should be and build a finish product.
The systems development life cycle (SDLC) is a conceptual model used in project management that describes the stages involved in an information system development project, from an initial feasibility study through maintenance of the completed application.

Various SDLC methodologies have been developed to guide the processes involved, including the waterfall model (which was the original SDLC method); rapid application development (RAD); joint application development (JAD); the fountain model; the spiral model; build and fix; and synchronize-and-stabilize. Frequently, several models are combined into some sort of hybrid methodology. Documentation is crucial regardless of the type of model chosen or devised for any application, and is usually done in parallel with the development process. Some methods work better for specific types of projects, but in the final analysis, the most important factor for the success of a project may be how closely the particular plan was followed.

In general, an SDLC methodology follows the following steps:
1. The existing system is evaluated. Deficiencies are identified. This can be done by interviewing users of the system and consulting with support personnel.
2. The new system requirements are defined. In particular, the deficiencies in the existing system must be addressed with specific proposals for improvement.
3. The proposed system is designed. Plans are laid out concerning the physical construction, hardware, operating systems, programming, communications, and security issues.
4. The new system is developed. The new components and programs must be obtained and installed. Users of the system must be trained in its use, and all aspects of performance must be tested. If necessary, adjustments must be made at this stage.
5. The system is put into use. This can be done in various ways. The new system can phased in, according to application or location, and the old system gradually replaced. In some cases, it may be more cost-effective to shut down the old system and implement the new system all at once.
6. Once the new system is up and running for a while, it should be exhaustively evaluated. Maintenance must be kept up rigorously at all times. Users of the system should be kept up-to-date concerning the latest modifications and procedures.
http://searchsoftwarequality.techtarget.com/sDefinition/0,,sid92_gci755068,00.html

The Systems Development Life Cycle (SDLC) is a conceptual model used in project management that describes the stages involved in an information system development project from an initial feasibility study through maintenance of the completed application. Various SDLC methodologies have been developed to guide the processes involved including the waterfall model (the original SDLC method), rapid application development
(RAD), joint application development (JAD), the fountain model and the spiral model. Mostly, several models are combined into some sort of hybrid methodology. Documentation is crucial regardless of the type of model chosen or devised for any application, and is usually done in parallel with the development process. Some methods work better for specific types of projects, but in the final analysis, the most important factor for the success of a project may be how closely particular plan was followed.
http://www.startvbdotnet.com/sdlc/sdlc.aspx

3 Systems Development Models

The Waterfall Model
The Waterfall Model is the earliest method of structured system development. Although it has come under attack in recent years for being too rigid and unrealistic when it comes to quickly meeting customer’s needs, the Waterfall Model is still widely used. It is attributed with providing the theoretical basis for other Process Models, because it most closely resembles a “generic” model for software development.

The Waterfall Model consists of the following steps:
• System Conceptualization. System Conceptualization refers to the consideration of all aspects of the targeted business function or process, with the goals of determining how each of those aspects relates with one another, and which aspects will be incorporated into the system.

• Systems Analysis. This step refers to the gathering of system requirements, with the goal of determining how these requirements will be accommodated in the system. Extensive communication between the customer and the developer is essential.

• System Design. Once the requirements have been collected and analyzed, it is necessary to identify in detail how the system will be constructed to perform necessary tasks. More specifically, the System Design phase is focused on the data requirements (what information will be processed in the system?), the software construction (how will the application be constructed?), and the interface construction (what will the system look like? What standards will be followed?).

• Coding. Also known as programming, this step involves the creation of the system software. Requirements and systems specifications from the System Design step are translated into machine readable computer code.

• Testing. As the software is created and added to the developing system, testing is performed to ensure that it is working correctly and efficiently. Testing is generally focused on two areas: internal efficiency and external effectiveness. The goal of external effectiveness testing is to verify that the software is functioning according to system design, and that it is performing all necessary functions or sub-functions. The goal of internal testing is to make sure that the computer code is efficient, standardized, and well documented. Testing can be a labor-intensive process, due to its iterative nature.

Problems/Challenges associated with the Waterfall Model
Although the Waterfall Model has been used extensively over the years in the production of many quality systems, it is not without its problems. In recent years it has come under attack, due to its rigid design and inflexible procedure. Criticisms fall into the following categories:
• Real projects rarely follow the sequential flow that the model proposes.
• At the beginning of most projects there is often a great deal of uncertainty about requirements and goals, and it is therefore difficult for customers to identify these criteria on a detailed level. The model does not accommodate this natural uncertainty very well.
• Developing a system using the Waterfall Model can be a long, painstaking process that does not yield a working version of the system until late in the process.

Iterative Development
The problems with the Waterfall Model created a demand for a new method of developing systems which could provide faster results, require less up-front information, and offer greater flexibility. With Iterative Development, the project is divided into small parts. This allows the development team to demonstrate results earlier on in the process and obtain valuable feedback from system users. Often, each iteration is actually a mini-Waterfall process with the feedback from one phase providing vital information for the design of the next phase. In a variation of this model, the software products which are produced at the end of each step (or series of steps) can go into production immediately as incremental releases.
http://www.ctg.albany.edu/publications/reports/survey_of_sysdev/survey_of_sysdev.pdf

Critic
One traditional process model is the waterfall model and according to Schacchi was only accepted just until the early 1980s because of its lack of functionality. The waterfall model is said to be the easiest model to understand and I do believe with this. It is easily understood because it provides a sequential succession of phases to be followed but then it is not that reliable. Just seeing a figure of the flow of the waterfall model you would just see the sequence of phases to go through but the problem here is it would not go through a cycle but just have a one-way flow just like a waterfall. Because of its simplicity it would only be suitable for certain classes of software development and would not work well with the other software like interactive applications. This model does not have risk management and management during the life cycle and mainly document-driven or code-driven that is why it would not work as smoothly as the other models.

Prototyping Model
The Prototyping Model was developed on the assumption that it is often difficult to know all of your requirements at the beginning of a project. Typically, users know many of the objectives that they wish to address with a system, but they do not know all the nuances of the data, nor do they know the details of the system features and capabilities. The Prototyping Model allows for these conditions, and offers a development approach that yields results without first requiring all information up-front .
When using the Prototyping Model, the developer builds a simplified version of the proposed system and presents it to the customer for consideration as part of the development process. The customer in turn provides feedback to the developer, who goes back to refine the system requirements to incorporate the additional information. Often, the prototype code is thrown away and entirely new programs are developed once requirements are identified.

There are a few different approaches that may be followed when using the Prototyping Model:
• creation of the major user interfaces without any substantive coding in the background in order to give the users a “feel” for what the system will look like,
• development of an abbreviated version of the system that performs a limited subset of functions; development of a paper system (depicting proposed screens, reports, relationships etc.), or
• use of an existing system or system components to demonstrate some functions that will be included in the developed system.

Prototyping is comprised of the following steps:
• Requirements Definition/Collection. Similar to the Conceptualization phase of the Waterfall Model, but not as comprehensive. The information collected is usually limited to a subset of the complete system requirements.
• Design. Once the initial layer of requirements information is collected, or new information is gathered, it is rapidly integrated into a new or existing design so that it may be folded into the prototype.
• Prototype Creation/Modification. The information from the design is rapidly rolled into a prototype. This may mean the creation/modification of paper information, new coding, or modifications to existing coding.
• Assessment. The prototype is presented to the customer for review. Comments and suggestions are collected from the customer.
• Prototype Refinement. Information collected from the customer is digested and the prototype is refined. The developer revises the prototype to make it more effective and efficient.
• System Implementation. In most cases, the system is rewritten once requirements are understood. Sometimes, the Iterative process eventually produces a working system that can be the cornserstone for the fully functional system.

Problems/Challenges associated with the Prototyping Model
Criticisms of the Prototyping Model generally fall into the following categories:
• Prototyping can lead to false expectations. Prototyping often creates a situation where the customer mistakenly believes that the system is “finished” when in fact it is not. More specifically, when using the Prototyping Model, the pre-implementation versions of a system are really nothing more than one-dimensional structures. The necessary, behindthe- scenes work such as database normalization, documentation, testing, and reviews for efficiency have not been done. Thus the necessary underpinnings for the system are not in place.
• Prototyping can lead to poorly designed systems. Because the primary goal of
Prototyping is rapid development, the design of the system can sometimes suffer because the system is built in a series of “layers” without a global consideration of the integration of all other components. While initial software development is often built to be a “throwaway, ” attempting to retroactively produce a solid system design can sometimes be problematic.

Variation of the Prototyping Model
A popular variation of the Prototyping Model is called Rapid Application Development (RAD).
RAD introduces strict time limits on each development phase and relies heavily on rapid application tools which allow for quick development.
http://www.ctg.albany.edu/publications/reports/survey_of_sysdev/survey_of_sysdev.pdf

Critic
The last model I am to discuss is the Rapid Prototyping Model. This model cannot be used in robust application. It is convenient because it is fast or rapid from the word itself. It can replace the specification phase but not the design phase because it mainly relates to the designing phase. In the waterfall model every phase should directly right at the first time while rapid prototyping changes frequently and the discarded if wrong.

The Spiral Model
The Spiral Model was designed to include the best features from the Waterfall and Prototyping
Models, and introduces a new component - risk-assessment. The term “spiral” is used to describe the process that is followed as the development of the system takes place. Similar to the
Prototyping Model, an initial version of the system is developed, and then repetitively modified based on input received from customer evaluations. Unlike the Prototyping Model, however, the development of each version of the system is carefully designed using the steps involved in the Waterfall Model. With each iteration around the spiral (beginning at the center and working outward), progressively more complete versions of the system are built.6
Risk assessment is included as a step in the development process as a means of evaluating each version of the system to determine whether or not development should continue. If the customer decides that any identified risks are too great, the project may be halted. For example, if a substantial increase in cost or project completion time is identified during one phase of risk assessment, the customer or the developer may decide that it does not make sense to continue with the project, since the increased cost or lengthened timeframe may make continuation of the project impractical or unfeasible.

The Spiral Model is made up of the following steps:
• Project Objectives. Similar to the system conception phase of the Waterfall Model.
Objectives are determined, possible obstacles are identified and alternative approaches are weighed.
• Risk Assessment. Possible alternatives are examined by the developer, and associated risks/problems are identified. Resolutions of the risks are evaluated and weighed in the consideration of project continuation. Sometimes prototyping is used to clarify needs.
• Engineering & Production. Detailed requirements are determined and the software piece is developed.
• Planning and Management. The customer is given an opportunity to analyze the results of the version created in the Engineering step and to offer feedback to the developer.
Problems/Challenges associated with the Spiral Model
Due to the relative newness of the Spiral Model, it is difficult to assess its strengths and weaknesses. However, the risk assessment component of the Spiral Model provides both developers and customers with a measuring tool that earlier Process Models do not have. The measurement of risk is a feature that occurs everyday in real-life situations, but (unfortunately) not as often in the system development industry. The practical nature of this tool helps to make the Spiral Model a more realistic Process Model than some of its predecessors.
http://www.ctg.albany.edu/publications/reports/survey_of_sysdev/survey_of_sysdev.pdf

Critic
Another traditional process model is the spiral model which is suggested by Barry Boehm in 1988. Spiral model is still regarded as one of the best model because it is a combination of the prototyping model and the waterfall model and comprises the strengths of the other software models.. According to Boehm, "the major distinguishing feature of the Spiral Model is that it creates a risk-driven approach to the software process rather than a primarily document-driven or code-driven process. It incorporates many of the strengths of other models and resolves many of their difficulties" [Boehm 1988]. This model is better that the waterfall because it may allow iteration. The main concept of the spiral model is that it aims to minimize risks with the use of repeated use of prototypes so that certain changes may be applied over again if there appears a problem upon the development.

SAD 1 - Assignment 3

System Analyst's Role as a Project Manager

On my previous assignment characteristics and skills of a system analyst was discussed as well as their roles. As a system analyst, one is responsible for the planning and recommending of suitable software for the company based on its requirements. So when we say a project manager, it has some similarities with the system analyst like planning but on different matters. A project manager plans, executes and closes a project. A project manager is responsible for one whole project while system analyst for a software or system.
Being a system analyst could also involve being project manager. Now what would be the role of a system analyst as a project manager? From the inputs I’ve gotten from the reports on our SAD class and interviews on the two organizations which are GH Office Depot and EMCOR, here are my answers to the question. A system analyst as s project manager examines the needs of the users so that they can produce or plan for a possible project as a solution. They survey department on who needs some improvements or review problems. After then they plan a project that would solve the problems and ease the needs of the users. He also manages the tasks and time needed for every project that is under development. He has the job to manage and see to it that the project is working well and everyone is doing their role to fulfill the goal of finishing the job.

According to Wikipedia a project manager is the person accountable for accomplishing the stated project objectives. Key project management responsibilities include creating clear and attainable project objectives, building the project requirements, and managing the triple constraint for projects, which are cost, time, and quality (also known as scope).
A project manager is often a client representative and has to determine and implement the exact needs of the client, based on knowledge of the firm they are representing. The ability to adapt to the various internal procedures of the contracting party, and to form close links with the nominated representatives, is essential in ensuring that the key issues of cost, time, quality and above all, client satisfaction, can be realized.
http://en.wikipedia.org/wiki/Project_manager

In general, the project manager is responsible for the overall success of the project. In some companies, this person might be called a Project Coordinator, or a Team Leader, however, the key aspect is that the person is responsible for ensuring the success of the project.
What does it take for the project to be a success? If you follow the TenStep Project Management Process or a similar approach, you first must define the project and build the schedule. This is where the project manager's responsibilities start. If the project begins and you find out later that you are not clear on scope, the project manager is the one who is accountable. If your project is executing a poor schedule, the project manager is accountable.
The work around defining the project means that you understand and gain agreement on the overall objectives, scope, risk, approach, budget, etc. It also includes defining or adopting the specific project management procedures that will be used to manage the project.
This does not mean that the project manager must do all this work themselves. There may be an entire team of people helping to create the Project Charter and schedule. However, if something does not go right, the project manager is accountable.
Once the project starts, the project manager must successfully manage and control the work, including:
• Identifying, tracking managing and resolving project issues
• Proactively disseminating project information to all stakeholders
• Identifying, managing and mitigating project risk
• Ensuring that the solution is of acceptable quality
• Proactively managing scope to ensure that only what was agreed to is delivered, unless changes are approved through scope management
• Defining and collecting metrics to give a sense for how the project is progressing and whether the deliverables produced are acceptable
• Managing the overall schedule to ensure work is assigned and completed on time and within budget
Again, this does not mean that the project manager physically does all of this, but they must make sure it happens. If the project has problems, or scope creep, or faces risks, or is not setting expectations correctly, then the project manager is the person held accountable.
To manage the project management processes, a person should be well organized, have great follow-up skills, be process oriented, be able to multi-task, have a logical thought process, be able to determine root causes, have good analytical ability, be a good estimator and budget manager, and have good self-discipline.
In addition to process skills, a project manager must have good people management skills. This includes:
• Having the discipline and general management skills to make sure that people follow the standard processes and procedures
• Establishing leadership skills to get the team to willingly follow your direction. Leadership is about communicating a vision and getting the team to accept it and strive to get there with you.
• Setting reasonable, challenging and clear expectations for people, and holding them accountable for meeting the expectations. This includes providing good performance feedback to team members
• Team building skills so that the people work together well, and feel motivated to work hard for the sake of the project and their other team members. The larger your team and the longer the project, the more important it is to have good team-building skills.
• Proactive verbal and written communicator skills, including good, active listening skills.
Again, you are responsible for the success of the project. If the team has poor morale and is missing deadlines, you need to try to resolve it. If team members don't understand exactly what they need to do and when it is due, then you are responsible.
http://www.lifecyclestep.com/open/407.1TheRoleoftheProjectManager.htm

A project manager must always be aware of what is happening to the project team to see to it that everything is working well. They have the great responsibility of making the project work. On our it is emphasized that the project manager should give effort to be responsible for the whole progress of the project and the possible outcome of he project being developed.

EMCOR interview

MIS 2 - Assignment 4

University IS Plan

Wew! I can’t imagine myself being asked by the university president to make the IS plan for the university. Just imagining it make it so tough. Haha Well these would be the possible steps I would have to propose in implementing an IS plan for the University.

1. Identifying the problem and needs

2. Ask for suggestions from the experts

3. Provide quality system- implementation

4. Monitor maintenance

5. Grant flexibility for possible enhancements

Now what is IS planning?

Strategic Information Systems Planning (SISP) is the process of aligning an organization's business strategy with effective computer-based information systems to achieve critical business objectives. SISP is a top concern of major executives and considerable resources (time and money) are spent in SISP activities. Many SISP initiatives are not successful due to the difficulty of implementing the recommendations. A significant problem is the Specification Gap between the description of the recommended systems and the detail needed for actual system implementation. Existing SISP methods do not provide sufficiently rigorous representations to specify detailed system recommendations. Box structures are proposed as a solution to this problem and a SISP process with embedded box structure methods is presented. We have used this innovative process in two SISP projects with large organizations. Partial results from one of the projects are presented as a case study to illustrate the use of box structures and their benefits

http://www.computer.org/portal/web/csdl/doi/10.1109/HICSS.2000.926735

Information has emerged as an agent of integration and the enabler of new competitiveness for today’s enterprise in the global marketplace. However, has the paradigm of strategic planning changed sufficiently to support the new role of information systems and technology? We reviewed the literature for commonly used or representative information planning methodologies and found that a new approach is needed. There are six methodologies reviewed in this paper. They all tend to regard planning as a separate stage which does not connect structurally and directly to the information systems development. An integration of planning with development and management through enterprise information resources - which capture and characterize the enterprise – will shorten the response cycle and even allow for economic evaluation of information system investment.

For a long time relationship between information system functions and corporate strategy was not of much interest to Top Management of firms. Information Systems were thought to be synonymous with corporate data processing and treated as some back-room operation in support of day-to-day mundane tasks (Rockart, 1979). In the 80’s and 90’s, however, there has been a growing realization of the need to make information systems of strategic importance to an organization. Consequently, strategic information systems planning (SISP) is a critical issue. In many industry surveys, improved SISP is often mentioned as the most serious challenge facing IS managers (Pavri and Ang, 1995, Beath and Orlikowski, 1994; Martin, 1993; Porter and Miller,

1985).

Planning for information systems, as for any other system, begins with the identification of needs. In order to be effective, development of any type of computer-based system should be a response to need--whether at the transaction processing level or at the more complex information and support systems levels. Such planning for information systems is much like strategic planning in management. Objectives, priorities, and authorization for information systems projects need to be formalized. The systems development plan should identify specific projects slated for the future, priorities for each project and for resources, general procedures, and constraints for each application area. The plan must be specific enough to enable understanding of each application and to know where it stands in the order of development. Also the plan should be flexible so that priorities can be adjusted if necessary. King (King, 1995) in his recent article has argued that a strategic capability architecture - a flexible and continuously improving infrastructure of organizational capabilities – is the primary basis for a company's sustainable competitive advantage. He has emphasized the need for continuously updating and improving the strategic capabilities architecture.

http://viu.eng.rpi.edu/publications/strpaper.pdf

Every year, $300-700 million dollar corporations spend about 5% of their gross income on information systems and their supports. That's from about $15,000,000 to $35,000,000! A significant part of those funds support enterprise databases, a philosophy of database system applications that enable corporations to research the past, control the present, and plan for the future.

Even though an information system costs from $1,000,000 to $10,000,000, and even through most chief information officers (CIOs) can specify exactly how much money is being spent for hardware, software, and staff, CIOs cannot however state with any degree of certainty why one system is being done this year versus next, why it is being done ahead of another, or finally, why it is being done at all.

Many enterprises do not have model-based information systems development environments that allow system designers to see the benefits of rearranging an information systems development schedule. Consequently, the questions that cannot be answered include:

* What effect will there be on the overall schedule if an information system is purchased versus developed?
* At what point does it pay to hire an abnormal quantity of contract staff to advance a schedule?
* What is the long term benefit from 4GL versus 3GL?
* Is it better to generate 3GL than to generate/use a 4GL?
* What are the real costs of distributed software development over centralized development?

If these questions were transformed and applied to any other component of a business (e.g., accounting, manufacturing, distribution and marketing), and remained unanswered, that unit's manager would surely be fired!

We not only need answers to these questions NOW!, we also need them quickly, cost effectively, and in a form that they can be modeled and changed in response to unfolding realities. This paper provides a brief review of a successful 10-step strategy that answers these questions.

Too many half-billion dollar organizations have only a vague notion of the names and interactions of the existing and under development information systems. Whenever they need to know, a meeting is held among the critical few, an inventory is taken, interactions confirmed, and accomplishment schedules are updated.

This ad hoc information systems plan was possible only because all design and development was centralized, the only computer was a main-frame, and the past was acceptable prologue because budgets were ever increasing, schedules always slipping, and information was not yet part of the corporation's critical edge.

Well, today is different, really different! Budgets are decreasing, and slipped schedules are being cited as preventing business alternatives. Confounding the computing environment are different operating systems, DBMSs, development tools, telecommunications (LAN, WAN, Intra-, Inter-, and Extra-net), and distributed hard- and software.

Rather than having centralized, long-range planning and management activities that address these problems, today's business units are using readily available tools to design and build ad hoc stop-gap solutions. These ad hoc systems not only do not interconnect, support common semantics, or provide synchronized views of critical corporate policy, they are soon to form the almost impossible to comprehend confusion of systems and data from which systems order and semantic harmony must spring.

Not only has the computing landscape become profoundly different and more difficult to comprehend, the need for just the right--and correct--information at just the right time is escalating. Late or wrong information is worse than no information.

Information systems managers need a model of their information systems environment. A model that is malleable. As new requirements are discovered, budgets modified, new hardware/software introduced, this model must be such that it can reconstitute the information systems plan in a timely and efficient manner.

http://www.tdan.com/view-articles/5262

1. Identifying a very clearly defined and specific problem is the first critical step to successfully implementing the problem-solving process. The strategy of improving the quality of services involves solving problems in order of priority. Why is it important to prioritize problems?

Resources and time are limited. You can't solve all the problems at the same time, so your efforts should initially focus on the most important problem.

To gain experience and acquire expertise with the problem-solving process, the first problem you work on should be one that is easily studied and resolved. Choose a problem with plenty of data easily available.

If the resolution of the first problem is successful, that solution can be reproduced easily at the local or national level, and even more so if it corresponds to the priority policies of the institution.

What?

A problem occurs when there is a difference between what "should be" and what "is"; between the ideal and the actual situation. A problem:

·expresses the difference between the hoped for and the actual situation;

·is directly or indirectly related to the health of the population;

·is expressed in terms of processes, effects, impacts, and satisfaction.

How?

You can select a problem by using one of the following techniques:

· a direct observation technique, such as a user survey

· a consensus technique like a prioritization matrix , which uses brainstorming as a first step

· a data analysis technique, such as using a control chart

http://erc.msh.org/quality/identify.cfm

2. Ask for experts suggestions

Though you are to provide plans you still have to ask for the experts advise because they know what is best for they have already gone through a lot.

The need for resources is a many-faceted issue. Some organizations are reluctant to commit to web accessibility, fearing that they do not have the necessary resources to follow-through on the commitment. Other organizations casually commit to accessibility without any intention of supporting this commitment in any real way. The process of making an accessible web site is not expensive, but it takes time to learn the techniques, and some kind of training is usually necessary, whether in the form of outside consultants, courses, workshops, or books. Ignoring the need for this kind of support will likely lead to frustrated web developers who feel that they have received a mandate with no knowledge of how to comply with it.
In some cases, the development process can be expensive, as in the case of accessible multimedia. If no resources are set aside for this sort of task, chances are low that the developers will produce an accessible product. However, in the overall scheme of multimedia development, the cost of adding accessibility features is relatively low. The multimedia product itself is expensive to produce.
It is always difficult to procure the money and other resources for large projects, but if the top level of an organization commits to accessibility, this provides justification for adding any costs associated with accessibility into the budget of projects. The leadership of the organization could even require that accessibility be a part of web projects. This will work best, of course, if the leadership actually sets aside some money for this purpose. Nobody likes the concept of unfunded mandates. At the very least, the leadership should provide educational resources, because once people learn the techniques of accessibility, it becomes an integral part of the web development process, rather than an expensive add-on.
At WebAIM, for example, we strive to make all of our content accessible. We could not easily give an accurate estimate of the amount of "extra time" that is required to make our content accessible. This time is not extra. It is required time. It is part of the process which we cannot separate out from the whole. And the truth is that the time We spend incorporating the accessibility features of our web content is minimal.

The real cost, and the real time investment in the development process is the up-front time of learning accessible design techniques. If an organization invests in training resources, most of the other development resource needs will diminish if not disappear.

3. Provide quality system suited for users- implementation

In the context of new devices and with a variety of network technologies that allow access to the Internet, the providers of e-learning materials have to ensure that the users have a positive experience using their e-learning systems and they are happy to re-use them. Adaptive Hypermedia research aims to provide personalised educational material that ensures a positive learning experience for the end-users. However, user experience is dependent not only on the content served to them, but also on the user perceived performance of the e-learning system. This leads to a new dimension of individual differences between Web users: the end-user Quality of Experience (QoE). We have proposed a solution for Adaptive Hypermedia Systems (AHS) that provides satisfactory end-user QoE through the use of a new QoE layer. This layer attempts to take into account multiple factors affecting QoE in relation to the delivery of a wide range of Web components such as text, images, video, audio.

The effectiveness of our QoE layer has been tested in comparison to a standard educational AHS and the results of these tests are presented in this paper. Different educational-based evaluation techniques such as learner achievement analysis, learning performance assessment, usability survey and correlation analysis between individual student performance and judgment on system usability were applied in order to fully assess the performance of the proposed QoE layer. Results of the tests showed that the use of the QoE layer brought significant improvements in terms of user learning performance, system usability and user satisfaction with the personalised e-learning system while not affecting the user learning achievement.

http://dialnet.unirioja.es/servlet/articulo?codigo=2284052

4. Monitor maintenance

n the early days, home computers were largely self-referential; people used them because they were interested in them. Now, computers are usually used for real-world tasks, yet they still need some navel-gazing attention at times!

The basic routine maintenance tasks are:

·Data backup

·Malware management

·File system maintenance

User data is unique to the installation and cannot be replaced 'off the peg', and for that reason it is the central concern of system management. There's a more rigorous coverage of data management, safe computing and malware elsewhere on this site; this is an easy how-to.

Backup

To backup is to create a redundant copy, so that if anything should happen to the original file, you have recourse to the backup. The process can be as simple as copying files to diskettes, but this soon becomes a problem where files are too big for diskette, where there are too many files, or where too many diskettes are required.

A better solution is to use an archiver (such as WinZip) or a backup utility to create a single compressed file from a collection of data files, and to split this over as many diskettes as required. This uses fewer diskettes and allows large files to be backed up even if the file is larger than a diskette can hold.

For large data sets, you may need to use a bulk storage medium such as tape, Zip disk, CDR or similar. These are generally faster and more reliable than diskettes.

The systems I set up will usually have a facility to backup data and core system files to the hard drive, and another to copy the most recent of such backups to diskettes. You should use this whenever you have done more work than you would want to redo from scratch. If your work is saved outside the designated data subtree then it won't be backed up by this process; you will have to make your own arrangements to back it up (WinZip, copy, etc.)

Malware management

There's more on safe computing and malware. Malware includes viruses, worms, trojans, and increasingly invasive commercial applications, and management has several parts:

· Risk avoidance and evaluation - choice of applications and system setup

· Risk avoidance and evaluation - user education and safe computing practice

· Risk detection and destruction - choice and use of antivirus software

· Keeping abreast of malware - antivirus updates and ongoing user education

Simply running an antivirus utility is not enough, even if it is kept up to date!

For best performance, you can use on-demand rather than on-access antivirus scanners - but this requires the user to know when to use this, and act accordingly.

Updating an antivirus generally involves these steps:

· Go to antivirus vendor's web site via (say) Internet Explorer

· Navigate to the download section of the site

· Download any updates that are relevant, noting where these are saved

· Extract files from downloaded archive to the antivirus program directory

Some Windows-based antivirus utilities may automate this process to some extent, by accessing the Internet directly from within the program. You should check for updates at least once a week, and make sure your antivirus data files do not become more than a month out of date.

File system maintenance

Much can be done during system setup to improve the survivability, maintainability and recoverability of the file system and its data, as discussed on the data management page. Thereafter, there are three tasks required on a regular basis:

· Check that sufficient free space is available; ideally 50M+ on C: volume

· Check the file system for errors, and manage these

· Defragment the file system once it is known to be error-free

The tools used here are Windows Explorer (or its "My Computer" incarnation), ScanDisk, and Defrag. If free space is low, you can clear .TMP files from the Windows base directory.

http://cquirke.mvps.org/9x/maintain.htm

5. Grant flexibility for possible enhancements

While insufficient flexibility of an information system to support a business process precludes the use of the system in certain cases, excessive flexibility of an information system can limit the usability of the system (Silver 1991), in addition to presenting an unnecessary investment. Despite a wealth of research on flexibility and its impacts on organizations and business processes (esp. manufacturing), the value of flexibility of an information system and the price at which it comes have rarely been included into the analysis, with the result that guidelines to determine an appropriate level of flexibility of an information system to support a given business process have not been developed. To support decisions regarding information system flexibility, the current paper presents an optimization model to relate business process characteristics (uncertainty, variability, and time−criticality) with two basic types of information system flexibility (built−in flexibility to use the information system and flexibility to change the information system). Based on an analysis of the model, we conclude that the focus of information system management should be on flexibility to change the information system in order to support processes of high uncertainty, while situations of low uncertainty tend to call for a focus on built−in flexibility to use the information system. The model also shows that very high process variability can limit the value of investments in an information system altogether, thus, improving the importance of careful flexibility and investment management, while a high level of time−criticality generally tends to increase the benefits of using an information system over manual

processing.

http://www.business.illinois.edu/Working_Papers/papers/05-0112.pdf