The question was consider your school, how do you know that the life cycle was developed specifically for the university. How do we know it meets our needs? This is the question that’s need to be answered in order for me to answer it I will need references from different articles on this matter. To start, I will give you some insight about our University which is the University of Southeastern Philippines.
USEP
The University of Southeastern Philippines (USEP) is a regional state university created in 1978 through Batas Pambansa Bilang 12. The university is an integration of four state institutions, particularly, the Mindanao State University-Davao, the University of the Philippines-Master of Management Program in Davao, the Davao School of Arts and Trades, and the Davao National Regional Agricultural School. The university has four campuses, namely, Obrero (main) and Mintal Campuses in Davao City, Tagum-Mabini Campus which has two units – one in Tagum City and one in Compostela Valley Province, and Bislig Campus in Surigao del Sur. The USEP offers graduate and undergraduate academic programs in the fields of engineering, education, arts and sciences, economics, business, computing, governance, development, resource management, technology, agriculture and forestry.
The University of Southeastern Philippines has the following mandate:
To provide programs of instruction and professional training primarily in the fields of science and technology, especially medicine, fisheries, engineering and industrial fields. To promote advanced studies, research and extension services and progressive leadership in science, agriculture, forestry, fisheries, engineering and industrial fields and other courses needed in the socio-economic development of Mindanao. To develop courses at the graduate level along the fields of specialization and to respond to the needs of development workers in the academic community. To provide non-formal education and undertake vigorous extension and research programs in food production, nutrition, and health and sports development. To offer scholarship and/or part-time job opportunities to deserving students from low-income families.
Now, the Mission of the University
USEP shall produce world-class graduates and relevant research and extension through quality education and sustainable resource management.
Particularly, USEP is committed to:
· Provide quality education for students to grow in knowledge, promote their well-rounded development, and make them globally competitive in the world of work;
· Engage in high impact research, not only for knowledge’s sake, but also for its practical benefits to society; and,
· Promote entrepreneurship and industry collaboration.
Now, the Vision of the University
A PREMIER UNIVERSITY IN THE ASEAN REGION
By becoming a premier university in the ASEAN Region, the USEP shall be a center of excellence and development, responsive and adaptive to fast-changing environments. USEP shall also be known as the leading university in the country that fosters innovation and applies knowledge to create value towards social, economic, and technological developments.
And lastly, the Goals of the University
Aligned with the university’s vision and mission are specific goals for Key Result Areas (KRA) on Instruction; Research, Development, and Extension; and Resource Management:
KRA 1. Instruction
Produce globally competitive and morally upright graduates
KRA 2. Research, Development, and Extension (RDE)
Develop a strong R, D, & E culture with competent human resource and responsive and relevant researches that are adopted and utilized for development
So basically, these are what the University is looking and aiming about. So the University had made some improvement during the past years of it’s existense such as the addition of the Institute of Computing in the year 1997, the new building which is the offices of different department is located such as the OSS office, the UGTO office, and the Clinic these are just improved infrastructure. Newly added internet library for the education department, the new Institute of Language, and other improvements that the University attained.
So why is it important?
In any organization there should be a plan? A business plan, a strategic plan, a systems development plan or any plan that supports the goals of an organization. The university is an organization that needs a well developed plan or shall we say a well planned plan. So considering the life cycle of the University it has a systems development life cycle that embodies the set goals of the University. The University which is an organization, go through different life-cycles just like people do. For example, people go through infancy, child-hood and early-teenage phases that are characterized by lots of rapid growth. People in these phases often do whatever it takes just to stay alive, for example, eating, seeking shelter and sleeping. Often, these people tend to make impulsive, highly reactive decisions based on whatever is going on around them at the moment. Start-up organizations are like this, too. Often, founders of the organization or program and its various members have to do whatever is necessary just to stay in business. Leaders make highly reactive, seat-of-the-pants decisions. They fear taking the time to slow down and do planning. In our comparison of organizations and programs to people, we note that, as people continue to mature, they begin to understand more about the world and themselves. Over time, they develop a certain kind of wisdom that sees them through many of the challenges in life and work. They learn to plan and to use a certain amount of discipline to carry through on those plans. They learn to manage themselves. To survive well into the future, organizations and programs must be able to do this, as well. Experienced leaders have learned to recognize the particular life cycle that an organization or program is going through. These leaders understand the types of problems faced by the organization or program during the life cycle. That understanding gives them a sense of perspective and helps them to decide how to respond to decisions and problems in the workplace. According to wikipedia.org an organizational life cycle is the life cycle of an organization from birth level to the termination.
There are five level/stages in any organization.
1. Birth - ("Can the dream be realized?")
2. Growth - ("How are we going to pull this off?")
3. Maturity - ("How can we build this to be viable?")
4. Decline - ("How can the momentum be sustained?")
5. Death - ("What do we need to redesign?")
Birth
This stage begins with a dream, vision and opportunity. Almost every church starts with a person, or group of persons, who has a vision. In their mind and spirit they see the potential, visualize plans, and the church is birthed. The infant church is characterized by strong commitment and purpose. Although they may feel uncertain about the future, the attitudes of those involved are positive and supportive. The young church requires much nurture and attention. Members are interdependent, totally involved and willing to work together. Those who don't share the dream and aren't willing to get involved will leave. The infant organization is action-oriented, opportunity-driven, and vision-focused. The birth stage requires a strong visionary leader who can maintain a high degree of commitment. The leader must maintain control and have significant input into the infant organization. It is normal at this stage that the leader be more hands-on and in control with little or no delegation, but if the work is to survive he must be willing to listen and include people. It is essential that the leader's family be supportive of him and the infant church, and that the larger organization to which the church is affiliated be supportive and provide external intervention and help as needed.
Growth
At this stage the church's beliefs, values, goals, structure, and actions become more formalized. The beliefs provide a doctrinal agreement for organizational action. The goals extend the organization's shared dream and the structure organizes the action. In this stage members tend to share a strong sense of mission and purpose. There is a high level of goal ownership by both leaders and members. Everyone feels involved, committing time and resources to the church. Volunteers are easily found. The scarcity of space because of rapid growth is a common characteristic in this stage. The early phase of the growing stage is marked by excitement. A negative result may be a tendency for leaders and members to become complacent. The new church may be like a baby that gets into everything and has trouble because it is uncoordinated. It may face a severe crisis precipitated by fast growth combined with lack of systems, finances, policies, and structure. Then it may experience a kind of second birth. As it was birthed physically the first time by the founding leader now it is being born emotionally apart from the founder. This second birth is more prolonged and painful than the first. Moving to the next stage depends on the development of policies and rules on what and what not to do. Leadership must learn to delegate authority not just responsibility. The growth stage may require a crisis to cure arrogance and push the church on to experience maximized effectiveness. The church must be able to focus its energies and resources and find the delicate balance between managing the organization and continuing to take risks.
Maturity
The maturity stage is still on the upside of the life cycle. It extends from about two-thirds of the way up to the peak. This stage is characterized by high visibility for the church. A strong understanding of its common purpose and mission continue to energize and drive the church. It knows what it is doing, where it is going and how to get there. It makes plans and then follows up on those plans. Members are enthusiastic and willing to get involved. New members are exceed and quickly find a place to become involved. The vision of the organization is becoming a reality as the organizational structure and functional systems are working to maximum efficiency. A strong results orientation increases the satisfaction of the members and newcomers. The church reaches out to others, developing its members, and living out its dream in Christian love. Structures and ministries are now created in response to new needs. Positive and effective delegation begins while new roles and responsibilities are created allowing more people to become involved. The church excels in performance and effectiveness in ministry. As a result it starts new ministries and programs. In the normal development of the church in the maturity stage there will not be enough well-trained people for the ministries. Although there is excitement, momentum and a willingness to volunteer, there are few who have been adequately trained. Training must become a major focus. The greatest challenge is for the organization to stay in the maturity stage full of vision and creativity while managing effectively and continuing to train people for leadership. Abnormal development occurs if the church does not redream the dream and allow creative minds to work. The maturity stage church feels alive and senses little need. This can lead into a maintenance mode. Since it is easier to administrate or manage than it is to be entrepreneurial the church has a tendency to begin to run on autopilot. Taking risks is replaced by playing it safe. When the church loses its entrepreneurial spirit, it begins to age.
Decline
This decline stage is characterized by a decline in the members' understanding of and commitment to the church's purpose. New members do not sense ownership of the church's purpose. They assume others to be responsible, so there is decline in involvement. To compensate for this decline more paid staff are needed. As the decline stage progresses, the church moves from nostalgia to questioning. In the nostalgia phase the group reflects on and longs for a comfortable past. You know the church has reached this phase when you hear: "I remember when." "We can't do that." "We've tried that and it didn't work." In the questioning phase, members initially question within themselves, concerning leadership and church problems. Then the questioning becomes more intense as groups begin to discuss problems. At this point, either the organization redefines itself and is revitalized by its dream, or its rate of decline accelerates. A polarization phase develops, characterized by a climate in which members mistakenly view each other as enemies, and conflict erupts. Leaders face a mounting challenge. As the aging stage progresses the tension between leaders and members builds. There is the increasing awareness that something is wrong but nobody knows what it is. Leaders are frustrated and seek to find answers. In an attempt to bring life the leader may suggest a new program or ministry and begin to implement it. The new ministry is placed into the existing structure of the church and brings some excitement and success, but soon the group is back at nostalgia and aging again. This cycle is repeated but each time with less excitement and effectiveness. The group moves from enthusiasm to frustration, to apathy and then to burnout. When this happens the leader's credibility is lost. The challenge for such a leader is not just to get a good idea for a new ministry but to redream the dream and somehow stimulate revitalization of the whole organization. The only hope is if leader and people can find a way to return to the birth stage and pray for a new vision.
Death
This fifth stage is characterized by the total loss of purpose and hope. The mission is not understood. As questioning and polarization increase, the emphasis shifts to who caused the problem, rather than what to do about it. There is the assumption that finding the who is solving the what. Conflict, back stabbing, and infighting abound. This polarization leads to either a splintering away or a split in the church. Paranoia freezes the church and everyone is lying low. Focus shifts to the internal turf wars while the unreached and the newcomer are seen as a nuisance and ignored. The church disassociates from its community and the people it should reach and focuses mostly on itself. Leadership is extremely frustrated to the point of despair by not knowing how to stop decline and the infighting in this stage. Frequently the leader is perceived as the problem which may or may not be the truth. Leadership takes many hard hits in the dying stage, particularly if the primary influencers do not support the leader. If the leader is visionary, creative and aggressive, he will likely not last long in the church or the group. if the leader is passive and maintenance oriented, he may make the patient comfortable while it continues to die. Few churches or groups ever truly recover at the dying stage. If they do it is because new leadership is able to revive the church with a vision and strategy. This requires also that the remaining members be willing to allow a heart transplant and add new life through new members.
So this is the organizational life cycle which is important for organizations such as the University in order to attain the goal that is intented to attain to be a premier University in the asean region. So in order to attain everyone must do its jobs in order to be more fruitful.
References:
http://webuildpeople.ag.org/wbp_library/9608_organization_lifecycl.cfm
http://en.wikipedia.org/wiki/Organizational_life_cycle
http://managementhelp.org/org_thry/org_cycl.htm
http://www.usep.edu.ph/version/
Sunday, January 3, 2010
Thursday, December 31, 2009
Assignment 4 in SAD
The question was to identify and discuss at least3 systems development models, and discuss each of them. So in order for me to answer the question I also need to identify and discuss to you what is a systems development models, its definition and functions. How important it is in an organization to achieve its goals. I will also identify 3 examples of systems development models that is commonly used system development models. Such as waterfall model, the v-model, and the spiral model. So I will discuss each of its functions and importance in systems development life cycle. But before that I will discuss first what is a systems development life cycle or model.
A systems development lifecycle (SDLC) has three primary objectives: ensure that high quality systems are delivered, provide strong management controls over the projects, and maximize the productivity of the systems staff. In order to meet these objectives the SDLC has many specific requirements it must meet, including: being able to support projects and systems of various scopes and types, supporting all of the technical activities, supporting all of the management activities, being highly usable, and providing guidance on how to install it. The technical activities include: system definition (analysis, design, coding), testing, system installation (e.g., training, data conversion), production support (e.g., problem management), defining releases, evaluating alternatives, reconciling information across phases and to a global view, and defining the project's technical strategy. The management activities include: setting priorities, defining objectives, project tracking and status reporting, change control, risk assessment, step wise commitment, cost/benefit analysis, user interaction, managing vendors, post implementation reviews, and quality assurance reviews. In order to meet all of the SDLC's objectives and requirements there are certain design approaches that are required: the SDLC must be an example of a system created using the techniques it espouses; it must use a layered approach to analysis, design, installation support and production support; it must keep distinct the "what" from the "how" in regards to doing the tasks and creating the outputs; and it must organize its information in a hierarchical manner so that users with varying degrees of familiarity can find what they want easily and quickly. Defining or selecting an SDLC should be undertaken as a project with full time resources who have the appropriate level of expertise. It is an extremely high leverage effort. It also represents a major cultural change for the staff. It must be planned and executed in as professional a manner as possible.
A Systems Development Life Cycle (SDLC) is any logical process used by a systems analyst to develop an information system, including requirements, validation, training, and user (stakeholder) ownership. Any SDLC should result in a high quality system that meets or exceeds customer expectations, reaches completion within time and cost estimates, works effectively and efficiently in the current and planned Information Technology infrastructure, and is inexpensive to maintain and cost-effective to enhance. Computer systems have become more complex and often (especially with the advent of Service-Oriented Architecture) link multiple traditional systems potentially supplied by different software vendors. To manage this level of complexity, a number of systems development life cycle (SDLC) models have been created: "waterfall"; "fountain"; "spiral"; "build and fix"; "rapid prototyping"; "incremental"; and "synchronize and stabilize". SDLC models can be described along a spectrum of agile to iterative to sequential. Agile methodologies, such as XP and Scrum, focus on light-weight processes which allow for rapid changes along the development cycle. Iterative methodologies, such as Rational Unified Process and Dynamic Systems Development Method, focus on limited project scopes and expanding or improving products by multiple iterations. Sequential or big-design-upfront (BDUF) models, such as Waterfall, focus on complete and correct planning to guide large projects and risks to successful and predictable results. Some agile and iterative proponents confuse the term SDLC with sequential or "more traditional" processes; however, SDLC is an umbrella term for all methodologies for the design, implementation, and release of software. In project management a project can be defined both with a project life cycle (PLC) and an SDLC, during which slightly different activities occur. According to Taylor (2004) "the project life cycle encompasses all the activities of the project, while the systems development life cycle focuses on realizing the product requirements".
Now after discussing all about SDLC I will now discuss the 3 systems development model that I had identified. First one is the waterfall model, or the most traditional model of all SDLC. According to wikipedia.org a waterfall model is a sequential software development process, in which progress is seen as flowing steadily downwards (like a waterfall) through the phases of Conception, Initiation, Analysis, Design (validation), Construction, Testing and maintenance. The waterfall development model has its origins in the manufacturing and construction industries; highly structured physical environments in which after-the-fact changes are prohibitively costly, if not impossible. Since no formal software development methodologies existed at the time, this hardware-oriented model was simply adapted for software development. The first formal description of the waterfall model is often cited to be an article published in 1970 by Winston W. Royce (1929–1995), although Royce did not use the term "waterfall" in this article. Royce was presenting this model as an example of a flawed, non-working model (Royce 1970). This is in fact the way the term has generally been used in writing about software development—as a way to criticize a commonly used software practice.
In Royce's original Waterfall model, the following phases are followed in order:
1. Requirements specification
2. Design
3. Construction (AKA implementation or coding)
4. Integration
5. Testing and debugging (AKA Validation)
6. Installation
7. Maintenance
Advantages of Waterfall Model
1. Clear project objectives.
2. Stable project requirements.
3. Progress of system is measurable.
4. Strict sign-off requirements.
Disadvantages of Waterfall Model
1. Time consuming
2. Never backward (Traditional)
3. Little room for iteration
4. Difficulty responding to changes
The Waterfall Model is the classic software life cycle model. According to Schach [1999], this model was the only widely accepted life cycle model until the early 1980s. This model represents the software life cycle using processes and products. Each process transforms a product to produce a new product as output. Then the new product becomes the input of the next process. The table below lists the processes and products of the Waterfall Model.
Notice that the output product on the right becomes the input product on the left of the process at the next lowest level. The general formula for describing the transformation of products by processes can be written as follows:
Each product is represented by a gray box and each process is represented by a solid arrow connecting the boxes. To learn more about these processes and products, view the Waterfall Model animation below.
So I think I have all discuss all the important things that are needed for you to understand all about the waterfall model, now we will go on to the next stage which is the V-model. According to wikipedia.org a v-model is a software development process which can be presumed to be the extension of the waterfall model. Instead of moving down in a linear way, the process steps are bent upwards after the coding phase, to form the typical V shape. The V-Model demonstrates the relationships between each phase of the development life cycle and its associated phase of testing. The V-model deploys a well-structured method in which each phase can be implemented by the detailed documentation of the previous phase. Testing activities like test designing start at the beginning of the project well before coding and therefore saves a huge amount of the project time. The V-model consists of a number of phases. The Verification Phases are on the left hand side of the V, the Coding Phase is at the bottom of the V and the Validation Phases are on the right hand side of the V. As shown below;
Verification Phases
Requirements analysis
In the Requirements analysis phase, the requirements of the proposed system are collected by analyzing the needs of the user(s). This phase is concerned about establishing what the ideal system has to perform. However it does not determine how the software will be designed or built. Usually, the users are interviewed and a document called the user requirements document is generated. The user requirements document will typically describe the system’s functional, physical, interface, performance, data, security requirements etc as expected by the user. It is one which the business analysts use to communicate their understanding of the system back to the users. The users carefully review this document as this document would serve as the guideline for the system designers in the system design phase. The user acceptance tests are designed in this phase. See also Functional requirements, its is to develop in testing in now a days
System Design
Systems design is the phase where system engineers analyze and understand the business of the proposed system by studying the user requirements document. They figure out possibilities and techniques by which the user requirements can be implemented. If any of the requirements are not feasible, the user is informed of the issue. A resolution is found and the user requirement document is edited accordingly. The software specification document which serves as a blueprint for the development phase is generated. This document contains the general system organization, menu structures, data structures etc. It may also hold example business scenarios, sample windows, reports for the better understanding. Other technical documentation like entity diagrams, data dictionary will also be produced in this phase. The documents for system testing is prepared in this phase.
Architecture Design
The phase of the design of computer architecture and software architecture can also be referred to as high-level design. The baseline in selecting the architecture is that it should realize all which typically consists of the list of modules, brief functionality of each module, their interface relationships, dependencies, database tables, architecture diagrams, technology details etc. The integration testing design is carried out in this phase.
Module Design
The module design phase can also be referred to as low-level design. The designed system is broken up into smaller units or modules and each of them is explained so that the programmer can start coding directly. The low level design document or program specifications will contain a detailed functional logic of the module, in pseudocode:
• database tables, with all elements, including their type and size
• all interface details with complete API references
• all dependency issues
• error message listings
• complete input and outputs for a module.
The unit test design is developed in this stage.
Validation Phases
Unit Testing
In the V-model of software development, unit testing implies the first stage of dynamic testing process. According to software development expert Barry Boehm, a fault discovered and corrected in the unit testing phase is more than a hundred times cheaper than if it is done after delivery to the customer. It involves analysis of the written code with the intention of eliminating errors. It also verifies that the codes are efficient and adheres to the adopted coding standards. Testing is usually white box. It is done using the Unit test design prepared during the module design phase. This may be carried out by software developers.
Integration Testing
In integration testing the separate modules will be tested together to expose faults in the interfaces and in the interaction between integrated components. Testing is usually black box as the code is not directly checked for errors.
System Testing
System testing will compare the system specifications against the actual system. The system test design is derived from the system design documents and is used in this phase. Sometimes system testing is automated using testing tools. Once all the modules are integrated several errors may arise. Testing done at this stage is called system testing.
User Acceptance Testing
Acceptance testing is the phase of testing used to determine whether a system satisfies the requirements specified in the requirements analysis phase. The acceptance test design is derived from the requirements document. The acceptance test phase is the phase used by the customer to determine whether to accept the system or not.
V-Model advantages:
• It is also called as verification and validation Model.
• This means the verification and validation will be done side by side.
• It emphasis the strict process flow to develop a quality product.
• The errors occurred in any phase will be corrected in that phase itself.
V-Model disadvantages:
• It needs lot of resources and money.
• It needs an established process to implement.
• It can be implemented by only some big companies.
So lastly, we wll now go to the last example which is the spiral model. According to wikipedia.org a spiral model is a software development process combining elements of both design and prototyping-in-stages, in an effort to combine advantages of top-down and bottom-up concepts. Also known as the spiral lifecycle model (or spiral development), it is a systems development method (SDM) used in information technology (IT). This model of development combines the features of the prototyping model and the waterfall model. The spiral model is intended for large, expensive and complicated projects.
History of the spiral model
The spiral model was defined by Barry Boehm in his 1988 article "A Spiral Model of Software Development and Enhancement”. This model was not the first model to discuss iterative development, but it was the first model to explain why the iteration matters. As originally envisioned, the iterations were typically 6 months to 2 years long. Each phase starts with a design goal and ends with the client (who may be internal) reviewing the progress thus far. Analysis and engineering efforts are applied at each phase of the project, with an eye toward the end goal of the project.
Steps
The steps in the spiral model iteration can be generalized as follows:
1. The new system requirements are defined in as much detail as possible. This usually involves interviewing a number of users representing all the external or internal users and other aspects of the existing system.
2. A preliminary design is created for the new system.This phase is the most important part of "Spiral Model". In this phase all possible (and available) alternatives, which can help in developing a cost effective project are analyzed and strategies are decided to use them. This phase has been added specially in order to identify and resolve all the possible risks in the project development. If risks indicate any kind of uncertainty in requirements, prototyping may be used to proceed with the available data and find out possible solution in order to deal with the potential changes in the requirements.
3. A first prototype of the new system is constructed from the preliminary design. This is usually a scaled-down system, and represents an approximation of the characteristics of the final product.
4. A second prototype is evolved by a fourfold procedure:
• evaluating the first prototype in terms of its strengths, weaknesses, and risks;
• defining the requirements of the second prototype;
• planning and designing the second prototype;
• constructing and testing the second prototype.
Spiral mostly Used
Game development is a main area where the spiral model is used and needed, that is because of the size and the constantly shifting goals of those large projects. The spiral model is mostly used in large projects. For smaller projects, the concept of agile software development is becoming a viable alternative. The US military has adopted the spiral model for its Future Combat Systems program. The FCS project was canceled after six years (2003 - 2009), it had a 2 year iteration (spiral). FCS should have resulted in 3 consecutive prototypes (one prototype per spiral - every 2 years). It was canceled in May, 2009
Advantages
1. This model improves avoidance of risk
2. This model is very useful to choose a methodology for a software iteration
3. This model can associate other methodologies like Waterfall, Prototyping, and Incremental methodologies. Suppose a project having a low risk of not meeting the user requirement and on other side having high risk of missing budget would follow waterfall approach
4. In this model more functionality can be added in later versions.
Disadvantages
1. This model limiting reusability
2. This model is quite complex
3. Spiral model is very customized for every project
4. To use this model an experienced and skilled team required
5. There is no proper control to move from one cycle to another cycle
In order to manage the risk of a single phase in the Spiral Model (i.e., one loop of the spiral), Boehm [1988] used the template below for risk assessment during the development of a software productivity tool. The rows of the template represented various management elements of the project. For each new phase, he created a new instance of the template to review the status of the project and decided whether the risks were too great to continue. To illustrate the use of the template, the rows have been filled with a fictitious example phase [Sommerville 1996].
Spiral Model Template
In the example above, software company A has the objective of significantly improving the quality of their software. In order to meet this goal, the company evaluates three alternatives and three risks. One of the alternatives is the use of formal specification and verification. This alternative, however, may incur the risk of causing existing staff to leave since they prefer to use more familiar methods of software development. To resolve this risk, staff training and motivation seminars are conducted to show the benefits of these new methods and determine the current level of expertise in formal methods. As a result, Company A discovers that the staff know very little about these methods. Therefore, it is difficult to estimate what type of benefit the company might receive from using this alternative to meet its objective. Since this option seems too risky, the plans for the next phase focus on another alternative that is more promising: the reuse of software components.
So to summarized it all, I had identified and discuss 3 examples of a systems development models. There are many systems development models that are available. It depends on what do you want to use in order to help you achieve what you are achieving for.
References:
http://www.blurtit.com/q7769291.html
http://courses.cs.vt.edu/csonline/SE/Lessons/Spiral/index.html
http://en.wikipedia.org/wiki/Spiral_model
http://www.allinterview.com/showanswers/33292.html
http://en.wikipedia.org/wiki/V-Model_(software_development)
http://courses.cs.vt.edu/csonline/SE/Lessons/Waterfall/index.html
http://en.wikipedia.org/wiki/Waterfall_model
http://en.wikipedia.org/wiki/Systems_Development_Life_Cycle
http://benderrbt.com/Bender-SDLC.pdf
http://www.blurtit.com/q533918.html
A systems development lifecycle (SDLC) has three primary objectives: ensure that high quality systems are delivered, provide strong management controls over the projects, and maximize the productivity of the systems staff. In order to meet these objectives the SDLC has many specific requirements it must meet, including: being able to support projects and systems of various scopes and types, supporting all of the technical activities, supporting all of the management activities, being highly usable, and providing guidance on how to install it. The technical activities include: system definition (analysis, design, coding), testing, system installation (e.g., training, data conversion), production support (e.g., problem management), defining releases, evaluating alternatives, reconciling information across phases and to a global view, and defining the project's technical strategy. The management activities include: setting priorities, defining objectives, project tracking and status reporting, change control, risk assessment, step wise commitment, cost/benefit analysis, user interaction, managing vendors, post implementation reviews, and quality assurance reviews. In order to meet all of the SDLC's objectives and requirements there are certain design approaches that are required: the SDLC must be an example of a system created using the techniques it espouses; it must use a layered approach to analysis, design, installation support and production support; it must keep distinct the "what" from the "how" in regards to doing the tasks and creating the outputs; and it must organize its information in a hierarchical manner so that users with varying degrees of familiarity can find what they want easily and quickly. Defining or selecting an SDLC should be undertaken as a project with full time resources who have the appropriate level of expertise. It is an extremely high leverage effort. It also represents a major cultural change for the staff. It must be planned and executed in as professional a manner as possible.
A Systems Development Life Cycle (SDLC) is any logical process used by a systems analyst to develop an information system, including requirements, validation, training, and user (stakeholder) ownership. Any SDLC should result in a high quality system that meets or exceeds customer expectations, reaches completion within time and cost estimates, works effectively and efficiently in the current and planned Information Technology infrastructure, and is inexpensive to maintain and cost-effective to enhance. Computer systems have become more complex and often (especially with the advent of Service-Oriented Architecture) link multiple traditional systems potentially supplied by different software vendors. To manage this level of complexity, a number of systems development life cycle (SDLC) models have been created: "waterfall"; "fountain"; "spiral"; "build and fix"; "rapid prototyping"; "incremental"; and "synchronize and stabilize". SDLC models can be described along a spectrum of agile to iterative to sequential. Agile methodologies, such as XP and Scrum, focus on light-weight processes which allow for rapid changes along the development cycle. Iterative methodologies, such as Rational Unified Process and Dynamic Systems Development Method, focus on limited project scopes and expanding or improving products by multiple iterations. Sequential or big-design-upfront (BDUF) models, such as Waterfall, focus on complete and correct planning to guide large projects and risks to successful and predictable results. Some agile and iterative proponents confuse the term SDLC with sequential or "more traditional" processes; however, SDLC is an umbrella term for all methodologies for the design, implementation, and release of software. In project management a project can be defined both with a project life cycle (PLC) and an SDLC, during which slightly different activities occur. According to Taylor (2004) "the project life cycle encompasses all the activities of the project, while the systems development life cycle focuses on realizing the product requirements".
Now after discussing all about SDLC I will now discuss the 3 systems development model that I had identified. First one is the waterfall model, or the most traditional model of all SDLC. According to wikipedia.org a waterfall model is a sequential software development process, in which progress is seen as flowing steadily downwards (like a waterfall) through the phases of Conception, Initiation, Analysis, Design (validation), Construction, Testing and maintenance. The waterfall development model has its origins in the manufacturing and construction industries; highly structured physical environments in which after-the-fact changes are prohibitively costly, if not impossible. Since no formal software development methodologies existed at the time, this hardware-oriented model was simply adapted for software development. The first formal description of the waterfall model is often cited to be an article published in 1970 by Winston W. Royce (1929–1995), although Royce did not use the term "waterfall" in this article. Royce was presenting this model as an example of a flawed, non-working model (Royce 1970). This is in fact the way the term has generally been used in writing about software development—as a way to criticize a commonly used software practice.
In Royce's original Waterfall model, the following phases are followed in order:
1. Requirements specification
2. Design
3. Construction (AKA implementation or coding)
4. Integration
5. Testing and debugging (AKA Validation)
6. Installation
7. Maintenance
Advantages of Waterfall Model
1. Clear project objectives.
2. Stable project requirements.
3. Progress of system is measurable.
4. Strict sign-off requirements.
Disadvantages of Waterfall Model
1. Time consuming
2. Never backward (Traditional)
3. Little room for iteration
4. Difficulty responding to changes
The Waterfall Model is the classic software life cycle model. According to Schach [1999], this model was the only widely accepted life cycle model until the early 1980s. This model represents the software life cycle using processes and products. Each process transforms a product to produce a new product as output. Then the new product becomes the input of the next process. The table below lists the processes and products of the Waterfall Model.
| Input Product | Process | Output Product |
| Communicated Requirements | Requirements Engineering | Requirements Specification Document |
| Requirements Specification Document | Design | Design Specification Document |
| Design Specification Document | Programming | Executable Software Modules |
| Executable Software Modules | Integration | Integrated Software Product |
| Integrated Software Product | Delivery | Delivered Software Product |
| Delivered Software Product | Maintenance | Changed Requirements |
Notice that the output product on the right becomes the input product on the left of the process at the next lowest level. The general formula for describing the transformation of products by processes can be written as follows:
Each product is represented by a gray box and each process is represented by a solid arrow connecting the boxes. To learn more about these processes and products, view the Waterfall Model animation below.
So I think I have all discuss all the important things that are needed for you to understand all about the waterfall model, now we will go on to the next stage which is the V-model. According to wikipedia.org a v-model is a software development process which can be presumed to be the extension of the waterfall model. Instead of moving down in a linear way, the process steps are bent upwards after the coding phase, to form the typical V shape. The V-Model demonstrates the relationships between each phase of the development life cycle and its associated phase of testing. The V-model deploys a well-structured method in which each phase can be implemented by the detailed documentation of the previous phase. Testing activities like test designing start at the beginning of the project well before coding and therefore saves a huge amount of the project time. The V-model consists of a number of phases. The Verification Phases are on the left hand side of the V, the Coding Phase is at the bottom of the V and the Validation Phases are on the right hand side of the V. As shown below;
Verification Phases
Requirements analysis
In the Requirements analysis phase, the requirements of the proposed system are collected by analyzing the needs of the user(s). This phase is concerned about establishing what the ideal system has to perform. However it does not determine how the software will be designed or built. Usually, the users are interviewed and a document called the user requirements document is generated. The user requirements document will typically describe the system’s functional, physical, interface, performance, data, security requirements etc as expected by the user. It is one which the business analysts use to communicate their understanding of the system back to the users. The users carefully review this document as this document would serve as the guideline for the system designers in the system design phase. The user acceptance tests are designed in this phase. See also Functional requirements, its is to develop in testing in now a days
System Design
Systems design is the phase where system engineers analyze and understand the business of the proposed system by studying the user requirements document. They figure out possibilities and techniques by which the user requirements can be implemented. If any of the requirements are not feasible, the user is informed of the issue. A resolution is found and the user requirement document is edited accordingly. The software specification document which serves as a blueprint for the development phase is generated. This document contains the general system organization, menu structures, data structures etc. It may also hold example business scenarios, sample windows, reports for the better understanding. Other technical documentation like entity diagrams, data dictionary will also be produced in this phase. The documents for system testing is prepared in this phase.
Architecture Design
The phase of the design of computer architecture and software architecture can also be referred to as high-level design. The baseline in selecting the architecture is that it should realize all which typically consists of the list of modules, brief functionality of each module, their interface relationships, dependencies, database tables, architecture diagrams, technology details etc. The integration testing design is carried out in this phase.
Module Design
The module design phase can also be referred to as low-level design. The designed system is broken up into smaller units or modules and each of them is explained so that the programmer can start coding directly. The low level design document or program specifications will contain a detailed functional logic of the module, in pseudocode:
• database tables, with all elements, including their type and size
• all interface details with complete API references
• all dependency issues
• error message listings
• complete input and outputs for a module.
The unit test design is developed in this stage.
Validation Phases
Unit Testing
In the V-model of software development, unit testing implies the first stage of dynamic testing process. According to software development expert Barry Boehm, a fault discovered and corrected in the unit testing phase is more than a hundred times cheaper than if it is done after delivery to the customer. It involves analysis of the written code with the intention of eliminating errors. It also verifies that the codes are efficient and adheres to the adopted coding standards. Testing is usually white box. It is done using the Unit test design prepared during the module design phase. This may be carried out by software developers.
Integration Testing
In integration testing the separate modules will be tested together to expose faults in the interfaces and in the interaction between integrated components. Testing is usually black box as the code is not directly checked for errors.
System Testing
System testing will compare the system specifications against the actual system. The system test design is derived from the system design documents and is used in this phase. Sometimes system testing is automated using testing tools. Once all the modules are integrated several errors may arise. Testing done at this stage is called system testing.
User Acceptance Testing
Acceptance testing is the phase of testing used to determine whether a system satisfies the requirements specified in the requirements analysis phase. The acceptance test design is derived from the requirements document. The acceptance test phase is the phase used by the customer to determine whether to accept the system or not.
V-Model advantages:
• It is also called as verification and validation Model.
• This means the verification and validation will be done side by side.
• It emphasis the strict process flow to develop a quality product.
• The errors occurred in any phase will be corrected in that phase itself.
V-Model disadvantages:
• It needs lot of resources and money.
• It needs an established process to implement.
• It can be implemented by only some big companies.
So lastly, we wll now go to the last example which is the spiral model. According to wikipedia.org a spiral model is a software development process combining elements of both design and prototyping-in-stages, in an effort to combine advantages of top-down and bottom-up concepts. Also known as the spiral lifecycle model (or spiral development), it is a systems development method (SDM) used in information technology (IT). This model of development combines the features of the prototyping model and the waterfall model. The spiral model is intended for large, expensive and complicated projects.
History of the spiral model
The spiral model was defined by Barry Boehm in his 1988 article "A Spiral Model of Software Development and Enhancement”. This model was not the first model to discuss iterative development, but it was the first model to explain why the iteration matters. As originally envisioned, the iterations were typically 6 months to 2 years long. Each phase starts with a design goal and ends with the client (who may be internal) reviewing the progress thus far. Analysis and engineering efforts are applied at each phase of the project, with an eye toward the end goal of the project.
Steps
The steps in the spiral model iteration can be generalized as follows:
1. The new system requirements are defined in as much detail as possible. This usually involves interviewing a number of users representing all the external or internal users and other aspects of the existing system.
2. A preliminary design is created for the new system.This phase is the most important part of "Spiral Model". In this phase all possible (and available) alternatives, which can help in developing a cost effective project are analyzed and strategies are decided to use them. This phase has been added specially in order to identify and resolve all the possible risks in the project development. If risks indicate any kind of uncertainty in requirements, prototyping may be used to proceed with the available data and find out possible solution in order to deal with the potential changes in the requirements.
3. A first prototype of the new system is constructed from the preliminary design. This is usually a scaled-down system, and represents an approximation of the characteristics of the final product.
4. A second prototype is evolved by a fourfold procedure:
• evaluating the first prototype in terms of its strengths, weaknesses, and risks;
• defining the requirements of the second prototype;
• planning and designing the second prototype;
• constructing and testing the second prototype.
Spiral mostly Used
Game development is a main area where the spiral model is used and needed, that is because of the size and the constantly shifting goals of those large projects. The spiral model is mostly used in large projects. For smaller projects, the concept of agile software development is becoming a viable alternative. The US military has adopted the spiral model for its Future Combat Systems program. The FCS project was canceled after six years (2003 - 2009), it had a 2 year iteration (spiral). FCS should have resulted in 3 consecutive prototypes (one prototype per spiral - every 2 years). It was canceled in May, 2009
Advantages
1. This model improves avoidance of risk
2. This model is very useful to choose a methodology for a software iteration
3. This model can associate other methodologies like Waterfall, Prototyping, and Incremental methodologies. Suppose a project having a low risk of not meeting the user requirement and on other side having high risk of missing budget would follow waterfall approach
4. In this model more functionality can be added in later versions.
Disadvantages
1. This model limiting reusability
2. This model is quite complex
3. Spiral model is very customized for every project
4. To use this model an experienced and skilled team required
5. There is no proper control to move from one cycle to another cycle
In order to manage the risk of a single phase in the Spiral Model (i.e., one loop of the spiral), Boehm [1988] used the template below for risk assessment during the development of a software productivity tool. The rows of the template represented various management elements of the project. For each new phase, he created a new instance of the template to review the status of the project and decided whether the risks were too great to continue. To illustrate the use of the template, the rows have been filled with a fictitious example phase [Sommerville 1996].
| Template | Explanation | Example Phase |
| Objectives | The goals of the software project | Significantly improve software quality |
| Constraints | Limitations which the project must meet | Within three years |
| Alternatives | Possible ways to achieve the objectives | Reuse existing certified software |
| Risks | Potential risks for this phase | No cost effective quality improvement possible |
| Risk Resolution | Strategies for reducing the risks | Literature survey, Pilot project, Survey of potential reusable components, Assessment of available tool support, Staff training and motivation seminars |
| Results | Results of applying risk resolution strategies | Experience of formal methods is limited - very hard to quantify improvements |
| Plans | Development plans for the next phase | Explore reuse option in more detail |
| Commitment | Resources needed to achieve the plans | Fund further 18-month study phase |
In the example above, software company A has the objective of significantly improving the quality of their software. In order to meet this goal, the company evaluates three alternatives and three risks. One of the alternatives is the use of formal specification and verification. This alternative, however, may incur the risk of causing existing staff to leave since they prefer to use more familiar methods of software development. To resolve this risk, staff training and motivation seminars are conducted to show the benefits of these new methods and determine the current level of expertise in formal methods. As a result, Company A discovers that the staff know very little about these methods. Therefore, it is difficult to estimate what type of benefit the company might receive from using this alternative to meet its objective. Since this option seems too risky, the plans for the next phase focus on another alternative that is more promising: the reuse of software components.
So to summarized it all, I had identified and discuss 3 examples of a systems development models. There are many systems development models that are available. It depends on what do you want to use in order to help you achieve what you are achieving for.
References:
http://www.blurtit.com/q7769291.html
http://courses.cs.vt.edu/csonline/SE/Lessons/Spiral/index.html
http://en.wikipedia.org/wiki/Spiral_model
http://www.allinterview.com/showanswers/33292.html
http://en.wikipedia.org/wiki/V-Model_(software_development)
http://courses.cs.vt.edu/csonline/SE/Lessons/Waterfall/index.html
http://en.wikipedia.org/wiki/Waterfall_model
http://en.wikipedia.org/wiki/Systems_Development_Life_Cycle
http://benderrbt.com/Bender-SDLC.pdf
http://www.blurtit.com/q533918.html
Wednesday, December 30, 2009
Critical Success Factors
For an introduction, first I will give insights about critical success factors. To start, so many important matters can compete for your attention in business that it's often difficult to see the "wood for the trees". What's more, it can be extremely difficult to get everyone in the team pulling in the same direction and focusing on the true essentials. That's where Critical Success Factors (CSFs) can help. CSFs are the essential areas of activity that must be performed well if you are to achieve the mission, objectives or goals for your business or project. By identifying your Critical Success Factors, you can create a common point of reference to help you direct and measure the success of your business or project. As a common point of reference, CSFs help everyone in the team to know exactly what's most important. And this helps people perform their own work in the right context and so pull together towards the same overall aims.
So the question is identify and discuss the steps for “critical success factors” approach. So this is the question that needs to be answered. But in order for me to answer it, I should discuss all about what is a “critical success factor”? so what is a critical success factor or (CSF), according to wikipedia.org it is the term for an element that is necessary for an organization or project to achieve its mission. It is a critical factor or activity required for ensuring the success of your business. The term was initially used in the world of data analysis, and business analysis. For example, a CSF for a successful Information Technology (IT) project is user involvement. Others also says that it is an an element of organizational activity which is central to its future success. Critical success factors may change over time, and may include items such as product quality, employee attitudes, manufacturing flexibility, and brand awareness. Or any of the aspects of a business that are identified as vital for successful targets to be reached and maintained. Critical success factors are normally identified in such areas as production processes, employee and organization skills, functions, techniques, and technologies. These are some of the definition about what critical success factor or (CSF) means. So we proceed to the next.
There are four basic types of CSF's
They are:
1. Industry CSF's resulting from specific industry characteristics;
2. Strategy CSF's resulting from the chosen competitive strategy of the business;
3. Environmental CSF's resulting from economic or technological changes; and
4. Temporal CSF's resulting from internal organizational needs and changes.
Things that are measured get done more often than things that are not measured. Each CSF should be measurable and associated with a target goal. You don't need exact measures to manage. Primary measures that should be listed include critical success levels (such as number of transactions per month) or, in cases where specific measurements are more difficult, general goals should be specified (such as moving up in an industry customer service survey). So next let us diccuss the factors involving CSF.
Factors:
· Money: positive cash flow, revenue growth, and profit margins.
· Your future: Acquiring new customers and/or distributors.
· Customer satisfaction: How happy they are.
· Quality: How good is your product and service?
· Product or service development: What's new that will increase business with existing customers and attract new ones?
· Intellectual capital: Increasing what you know is profitable.
· Strategic relationships: New sources of business, products and outside revenue.
· Employee attraction and retention: Your ability to extend your reach.
· Sustainability: Your personal ability to keep it all going.
Typically, critical success factors can be categorized into five primary categories:
1. leadership;
2. culture;
3. structure, roles, and responsibilities;
4. information technology infrastructure; and
5. measurement.
Leadership plays a key role in ensuring success in almost any initiative within an organization. Nothing makes greater impact on an organization than when leaders model the behavior they are trying to promote among employees.
Culture is the combination of shared history, expectations, unwritten rules, and social customs that
compel behaviors. It is the set of underlying beliefs that, while rarely exactly articulated, are always there to influence the perception of actions and communications of all employees.
Cultural issues concerning KM initiatives usually arise due to the following factors:
· Lack of time
· Unconnected reward systems
· Lack of common perspectives
· No formal communication
Structure, Roles, and Responsibilities
Although the structure is put in place to establish ownership and accountability, if there is no overall
ownership of knowledge and learning within the organization and the leadership does not "walk the talk," it will be difficult to sustain any sharing behavior.
Information Technology (IT) Infrastructure
Without a solid IT infrastructure, an organization cannot enable its employees to share information on a
large scale. Yet the trap that most organizations fall into is not a lack of IT, but rather too much focus on
IT.
Success factors related to IT.
· Approach
· Content
· Common platforms
· Simple technology
· Adequate training
Measurement
Because many variables may affect an outcome, it is important to correlate activities with business
outcomes, while not claiming a pure cause-and-effect relationship. Increased sales may be a result not
only of the sales representatives having more information, but also of the market turning, a competitor
closing down, or prices dropping 10 percent. Due to the inability to completely isolate knowledge-sharing results, tracking the correlations over time is important.
Start with a vision:
· Mission statement
· Develop 5-6 high level goals
· Develop hierarchy of goals and their success factors
· Lists of requirements, problems, and assumptions
· Leads to concrete requirements at the lowest level of decomposition (a single, implementable idea) Along the way, identify the problems being solved and the assumptions being made Cross-reference usage scenarios and problems with requirements
· Analysis matrices
· Problems vs. Requirements matrix
· Usage scenarios vs. Requirements matrix
· Solid usage scenarios
· Relationship to Usage Scenarios
· Usage scenarios or "use cases"; provide a means of determining:
o Are the requirements aligned and self-consistent?
o Are the needs of the user being met as well as those of the enterprise?
o Are the requirements complete
· Results of the Analysis
Now, I will give examples of CSF.
Statistical research into CSF’s on organizations has shown there to be seven key areas. These CSF's are:
1. Training and education
2. Quality data and reporting
3. Management commitment, customer satisfaction
4. Staff Orientation
5. Role of the quality department
6. Communication to improve quality, and
7. Continuous improvement
These were identified when Total Quality was at its peak, so as you can see have a bias towards quality matters. You may or may not feel that these are right or indeed critical for your organization.
The Critical Success Factors we have identified and us in the BIR process are captured in the mnemonic PRIMO-F
1. People - availability, skills and attitude
2. Resources - People, equipment, etc
3. Innovation - ideas and development
4. Marketing - supplier relation, customer satisfaction, etc
5. Operations - continuous improvement, quality,
6. Finance- cash flow, available investment etc
Steps in identifying CSF.
In reality, identifying your CSFs is a very iterative process. Your mission, strategic goals and CSFs are intrinsically linked and each will be refined as you develop them.
Here are the summary steps that, used iteratively, will help you identify the CSFs for your business or project:
Step 1:
Establish your business's or project's mission and strategic goals
Step 2:
For each strategic goal, ask yourself "what area of business or project activity is essential to achieve this goal?" The answers to the question are your candidate CSFs.
Tip: How Many CSFs?
To make sure you consider all types of possible CSFs, you can use Rockart's CSF types as a checklist.
· Industry - these factors result from specific industry characteristics. These are the things that the organization must do to remain competitive.
· Environmental - these factors result from macro-environmental influences on an organization. Things like the business climate, the economy, competitors, and technological advancements are included in this category.
· Strategic - these factors result from the specific competitive strategy chosen by the organization. The way in which the company chooses to position themselves, market themselves, whether they are high volume low cost or low volume high cost producers, etc.
· Temporal - these factors result from the organization's internal forces. Specific barriers, challenges, directions, and influences will determine these CSFs.
Step 3:
Evaluate the list of candidate CSFs to find the absolute essential elements for achieving success - these are your Criticial Success Factors.
As you identify and evaluate candidate CSFs, you may uncover some new strategic objectives or more detailed objectives. So you may need to define your mission, objectives and CSFs iteratively.
Step 4:
Identify how you will monitor and measure each of the CSFs.
Step 5:
Communicate your CSFs along with the other important elements of your business or project's strategy.
Step 6:
Keep monitoring and reevaluating your CSFs to ensure you keep moving towards your aims. Indeed, whilst CSFs are sometimes less tangible than measurable goals, it is useful to identify as specifically as possible how you can measure or monitor each one.
And lastly, I will just share a little CSF on DLPC. This is the data I gathered during the interview. Critical success factors that involve DLPC is their peopleware, project cost, support from business owner, time, and budget. These are the factors that is critical to the success of a project. So these are all I want to share. Thanks!
References:
http://docs.google.com
http://en.wikipedia.org/wiki/Critical_success_factor
http://www.mindtools.com/pages/article/newLDR_80.htm
http://rapidbi.com/created/criticalsuccessfactors.html
So the question is identify and discuss the steps for “critical success factors” approach. So this is the question that needs to be answered. But in order for me to answer it, I should discuss all about what is a “critical success factor”? so what is a critical success factor or (CSF), according to wikipedia.org it is the term for an element that is necessary for an organization or project to achieve its mission. It is a critical factor or activity required for ensuring the success of your business. The term was initially used in the world of data analysis, and business analysis. For example, a CSF for a successful Information Technology (IT) project is user involvement. Others also says that it is an an element of organizational activity which is central to its future success. Critical success factors may change over time, and may include items such as product quality, employee attitudes, manufacturing flexibility, and brand awareness. Or any of the aspects of a business that are identified as vital for successful targets to be reached and maintained. Critical success factors are normally identified in such areas as production processes, employee and organization skills, functions, techniques, and technologies. These are some of the definition about what critical success factor or (CSF) means. So we proceed to the next.
There are four basic types of CSF's
They are:
1. Industry CSF's resulting from specific industry characteristics;
2. Strategy CSF's resulting from the chosen competitive strategy of the business;
3. Environmental CSF's resulting from economic or technological changes; and
4. Temporal CSF's resulting from internal organizational needs and changes.
Things that are measured get done more often than things that are not measured. Each CSF should be measurable and associated with a target goal. You don't need exact measures to manage. Primary measures that should be listed include critical success levels (such as number of transactions per month) or, in cases where specific measurements are more difficult, general goals should be specified (such as moving up in an industry customer service survey). So next let us diccuss the factors involving CSF.
Factors:
· Money: positive cash flow, revenue growth, and profit margins.
· Your future: Acquiring new customers and/or distributors.
· Customer satisfaction: How happy they are.
· Quality: How good is your product and service?
· Product or service development: What's new that will increase business with existing customers and attract new ones?
· Intellectual capital: Increasing what you know is profitable.
· Strategic relationships: New sources of business, products and outside revenue.
· Employee attraction and retention: Your ability to extend your reach.
· Sustainability: Your personal ability to keep it all going.
Typically, critical success factors can be categorized into five primary categories:
1. leadership;
2. culture;
3. structure, roles, and responsibilities;
4. information technology infrastructure; and
5. measurement.
Leadership plays a key role in ensuring success in almost any initiative within an organization. Nothing makes greater impact on an organization than when leaders model the behavior they are trying to promote among employees.
Culture is the combination of shared history, expectations, unwritten rules, and social customs that
compel behaviors. It is the set of underlying beliefs that, while rarely exactly articulated, are always there to influence the perception of actions and communications of all employees.
Cultural issues concerning KM initiatives usually arise due to the following factors:
· Lack of time
· Unconnected reward systems
· Lack of common perspectives
· No formal communication
Structure, Roles, and Responsibilities
Although the structure is put in place to establish ownership and accountability, if there is no overall
ownership of knowledge and learning within the organization and the leadership does not "walk the talk," it will be difficult to sustain any sharing behavior.
Information Technology (IT) Infrastructure
Without a solid IT infrastructure, an organization cannot enable its employees to share information on a
large scale. Yet the trap that most organizations fall into is not a lack of IT, but rather too much focus on
IT.
Success factors related to IT.
· Approach
· Content
· Common platforms
· Simple technology
· Adequate training
Measurement
Because many variables may affect an outcome, it is important to correlate activities with business
outcomes, while not claiming a pure cause-and-effect relationship. Increased sales may be a result not
only of the sales representatives having more information, but also of the market turning, a competitor
closing down, or prices dropping 10 percent. Due to the inability to completely isolate knowledge-sharing results, tracking the correlations over time is important.
Start with a vision:
· Mission statement
· Develop 5-6 high level goals
· Develop hierarchy of goals and their success factors
· Lists of requirements, problems, and assumptions
· Leads to concrete requirements at the lowest level of decomposition (a single, implementable idea) Along the way, identify the problems being solved and the assumptions being made Cross-reference usage scenarios and problems with requirements
· Analysis matrices
· Problems vs. Requirements matrix
· Usage scenarios vs. Requirements matrix
· Solid usage scenarios
· Relationship to Usage Scenarios
· Usage scenarios or "use cases"; provide a means of determining:
o Are the requirements aligned and self-consistent?
o Are the needs of the user being met as well as those of the enterprise?
o Are the requirements complete
· Results of the Analysis
Now, I will give examples of CSF.
Statistical research into CSF’s on organizations has shown there to be seven key areas. These CSF's are:
1. Training and education
2. Quality data and reporting
3. Management commitment, customer satisfaction
4. Staff Orientation
5. Role of the quality department
6. Communication to improve quality, and
7. Continuous improvement
These were identified when Total Quality was at its peak, so as you can see have a bias towards quality matters. You may or may not feel that these are right or indeed critical for your organization.
The Critical Success Factors we have identified and us in the BIR process are captured in the mnemonic PRIMO-F
1. People - availability, skills and attitude
2. Resources - People, equipment, etc
3. Innovation - ideas and development
4. Marketing - supplier relation, customer satisfaction, etc
5. Operations - continuous improvement, quality,
6. Finance- cash flow, available investment etc
Steps in identifying CSF.
In reality, identifying your CSFs is a very iterative process. Your mission, strategic goals and CSFs are intrinsically linked and each will be refined as you develop them.
Here are the summary steps that, used iteratively, will help you identify the CSFs for your business or project:
Step 1:
Establish your business's or project's mission and strategic goals
Step 2:
For each strategic goal, ask yourself "what area of business or project activity is essential to achieve this goal?" The answers to the question are your candidate CSFs.
Tip: How Many CSFs?
To make sure you consider all types of possible CSFs, you can use Rockart's CSF types as a checklist.
· Industry - these factors result from specific industry characteristics. These are the things that the organization must do to remain competitive.
· Environmental - these factors result from macro-environmental influences on an organization. Things like the business climate, the economy, competitors, and technological advancements are included in this category.
· Strategic - these factors result from the specific competitive strategy chosen by the organization. The way in which the company chooses to position themselves, market themselves, whether they are high volume low cost or low volume high cost producers, etc.
· Temporal - these factors result from the organization's internal forces. Specific barriers, challenges, directions, and influences will determine these CSFs.
Step 3:
Evaluate the list of candidate CSFs to find the absolute essential elements for achieving success - these are your Criticial Success Factors.
As you identify and evaluate candidate CSFs, you may uncover some new strategic objectives or more detailed objectives. So you may need to define your mission, objectives and CSFs iteratively.
Step 4:
Identify how you will monitor and measure each of the CSFs.
Step 5:
Communicate your CSFs along with the other important elements of your business or project's strategy.
Step 6:
Keep monitoring and reevaluating your CSFs to ensure you keep moving towards your aims. Indeed, whilst CSFs are sometimes less tangible than measurable goals, it is useful to identify as specifically as possible how you can measure or monitor each one.
And lastly, I will just share a little CSF on DLPC. This is the data I gathered during the interview. Critical success factors that involve DLPC is their peopleware, project cost, support from business owner, time, and budget. These are the factors that is critical to the success of a project. So these are all I want to share. Thanks!
References:
http://docs.google.com
http://en.wikipedia.org/wiki/Critical_success_factor
http://www.mindtools.com/pages/article/newLDR_80.htm
http://rapidbi.com/created/criticalsuccessfactors.html
Friday, December 25, 2009
Systems Analyst as a Project Manager
To start, let me differentiate a systems analyst to a project manager. A project manager is a professional in the field of project management. Project managers can have the responsibility of the planning, execution, and closing of any project, typically relating to construction industry, architecture, computer networking, telecommunications or software development. 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.
Responsibilities
The specific responsibilities of the Project Manager vary depending on the industry, the company size, the company maturity, and the company culture. However, there are some responsibilities that are common to all Project Managers,
· Developing the project plan
· Managing the project stakeholders
· Managing the project team
· Managing the project risk
· Managing the project schedule
· Managing the project budget
· Managing the project conflicts
Project management
Project Management is quite often the province and responsibility of an individual project manager. This individual seldom participates directly in the activities that produce the end result, but rather strives to maintain the progress and mutual interaction and tasks of various parties in such a way that reduces the risk of overall failure, maximizes benefits, and restricts costs.
Products and services
Any type of product or service — pharmaceuticals, building construction, vehicles, electronics, computer software, financial services, etc. — may have its implementation overseen by a project manager and its operations by a product manager.
Project tools
The tools, knowledge and techniques for managing projects are often unique to Project Management. For example: work breakdown structures, critical path analysis and earned value management. Understanding and applying the tools and techniques which are generally recognized as good practices are not sufficient alone for effective project management. Effective project management requires that the project manager understands and uses the knowledge and skills from at least four areas of expertise. Examples are PMBOK, Application Area Knowledge: standards and regulations set forth by ISO for project management, General Management Skills and Project Environment Management[1]
Project teams
When recruiting and building an effective team, the manager must consider not only the technical skills of each person, but also the critical roles and chemistry between workers. A project team has mainly three separate components: Project Manager, Core Team and Contracted Team.
Risk
Most of the project management issues that influence a project arise from risk, which in turn arises from uncertainty. The successful project manager focuses on this as his/her main concern and attempts to reduce risk significantly, often by adhering to a policy of open communication, ensuring that project participants can voice their opinions and concerns.
While, a systems analyst is responsible for researching, planning, coordinating and recommending software and system choices to meet an organization's business requirements. The systems analyst plays a vital role in the systems development process. A successful systems analyst must acquire four skills: analytical, technical, managerial, and interpersonal. Analytical skills enable systems analysts to understand the organization and its functions, which helps him/her to identify opportunities and to analyze and solve problems. Technical skills help systems analysts understand the potential and the limitations of information technology. The systems analyst must be able to work with various programming languages, operating systems, and computer hardware platforms. Management skills help systems analysts manage projects, resources, risk, and change. Interpersonal skills help systems analysts work with end users as well as with analysts, programmers, and other systems professionals.
So basically, a systems analyst is also a project manager in a way that they both responsible for planning systems and other task.
The Reasons to Initiate IS Project
· The new information system is part of an overall strategic plan.
· The new information system is to respond an immediate business need.
What Is a Project?
· A project is a planned undertaking with a beginning and an end that produce predetermined result and is usually constrained by a schedule and resource.
Reasons for Project Failure
· Incomplete or changing requirements
· Limited user involvement
· Lack of executive support
· Lack of technical support
· Poor project planning
· Unclear objectives
· Lack of required resources
Reasons for Project Success
· Clear system requirement definitions
· Substantial user involvement
· Support from upper management
· Thorough and detailed project plans
· Realistic work schedules and milestones
Project Management
· Project management is organizing and directing people to achieve a planned result within budget and on schedule.
· Success or failure of project depends on skills of the project manager.
· The responsibilities of project manager are both internal and external
Internal Responsibilities of the Project Manager
· Identify project tasks and build a work breakdown structure
· Develop the project schedule
· Recruit and train team members
· Assign team members to tasks
· Coordinate activities of team members and subteams
· Assess project risks
· Monitor and control project deliverables and milestones
· Verify the quality of project deliverables
External Responsibilities of the Project Manager
· Report the project’s status and progress
· Establish good working relationships with those who identify the needed system requirements
· The people who will use the system
· Work directly with the client (the project’s sponsor) and other stakeholders
· Identify resource needs and obtain resources
Various Titles/Roles of Project Managers
Project Management Tasks
· Beginning of project
· Overall project planning
· During project
· Project execution management
· Project control management
· Project closeout
· Project management approach differs for
· Predictive SDLC
· Adaptive SDLC
·
System Development Life Cycle (SDLC)
· Project planning – initiate, ensure feasibility, plan schedule, obtain approval for project
· Analysis – understand business needs and processing requirements
· Design – define solution system based on requirements and analysis decisions
· Implementation – construct, test, train users, and install new system
· Support – keep system running and improve
Project Management Body of Knowledge
· Scope management
· Control functions included in system
· Control scope of work done by team
· Time management
· Build detailed schedule of all project tasks
· Monitor progress of project against milestones
· Cost management
· Calculate initial cost/benefit analysis
· Monitor expenses
Project Management Body of Knowledge (continued)
· Quality management
· Establish quality plan and control activities for each project phase
· Human resource management
· Recruit and hire project team members
· Train, motivate, team build
· Communications management
· Identify stakeholders and their communications
· Establish team communications
Project Management Body of Knowledge (continued)
· Risk management
· Identify and review risks for failure
· Develop plans to reduce these risks
· Procurement management
· Develop requests for proposals (RFPs)
· Evaluate bids, write contracts, monitor performance
· Integration management
Three Driving Forces to Start IS Project
· Respond to opportunity
· Top-down
· Resolve problem
· Bottom-up
· Conform to directive
· Legislative changes
So basically, in connection to what I have interviewed, he is a systems analyst of the Davao Light and Power Company. He stated that all of the jobs in their department is focused on supporting all the processes in their organization. They can suggest projects to the top management, but basically all projects are for fast processing to other departments and support type. So basically, they come up with projects but still they depend on the top management.
Appendixes:
References:
www.itk.ilstu.edu/.../Chapter%203%20-%20Analyst%20as%20a%20Project%20Manager.ppt
http://en.wikipedia.org/
Responsibilities
The specific responsibilities of the Project Manager vary depending on the industry, the company size, the company maturity, and the company culture. However, there are some responsibilities that are common to all Project Managers,
· Developing the project plan
· Managing the project stakeholders
· Managing the project team
· Managing the project risk
· Managing the project schedule
· Managing the project budget
· Managing the project conflicts
Project management
Project Management is quite often the province and responsibility of an individual project manager. This individual seldom participates directly in the activities that produce the end result, but rather strives to maintain the progress and mutual interaction and tasks of various parties in such a way that reduces the risk of overall failure, maximizes benefits, and restricts costs.
Products and services
Any type of product or service — pharmaceuticals, building construction, vehicles, electronics, computer software, financial services, etc. — may have its implementation overseen by a project manager and its operations by a product manager.
Project tools
The tools, knowledge and techniques for managing projects are often unique to Project Management. For example: work breakdown structures, critical path analysis and earned value management. Understanding and applying the tools and techniques which are generally recognized as good practices are not sufficient alone for effective project management. Effective project management requires that the project manager understands and uses the knowledge and skills from at least four areas of expertise. Examples are PMBOK, Application Area Knowledge: standards and regulations set forth by ISO for project management, General Management Skills and Project Environment Management[1]
Project teams
When recruiting and building an effective team, the manager must consider not only the technical skills of each person, but also the critical roles and chemistry between workers. A project team has mainly three separate components: Project Manager, Core Team and Contracted Team.
Risk
Most of the project management issues that influence a project arise from risk, which in turn arises from uncertainty. The successful project manager focuses on this as his/her main concern and attempts to reduce risk significantly, often by adhering to a policy of open communication, ensuring that project participants can voice their opinions and concerns.
While, a systems analyst is responsible for researching, planning, coordinating and recommending software and system choices to meet an organization's business requirements. The systems analyst plays a vital role in the systems development process. A successful systems analyst must acquire four skills: analytical, technical, managerial, and interpersonal. Analytical skills enable systems analysts to understand the organization and its functions, which helps him/her to identify opportunities and to analyze and solve problems. Technical skills help systems analysts understand the potential and the limitations of information technology. The systems analyst must be able to work with various programming languages, operating systems, and computer hardware platforms. Management skills help systems analysts manage projects, resources, risk, and change. Interpersonal skills help systems analysts work with end users as well as with analysts, programmers, and other systems professionals.
So basically, a systems analyst is also a project manager in a way that they both responsible for planning systems and other task.
The Reasons to Initiate IS Project
· The new information system is part of an overall strategic plan.
· The new information system is to respond an immediate business need.
What Is a Project?
· A project is a planned undertaking with a beginning and an end that produce predetermined result and is usually constrained by a schedule and resource.
Reasons for Project Failure
· Incomplete or changing requirements
· Limited user involvement
· Lack of executive support
· Lack of technical support
· Poor project planning
· Unclear objectives
· Lack of required resources
Reasons for Project Success
· Clear system requirement definitions
· Substantial user involvement
· Support from upper management
· Thorough and detailed project plans
· Realistic work schedules and milestones
Project Management
· Project management is organizing and directing people to achieve a planned result within budget and on schedule.
· Success or failure of project depends on skills of the project manager.
· The responsibilities of project manager are both internal and external
Internal Responsibilities of the Project Manager
· Identify project tasks and build a work breakdown structure
· Develop the project schedule
· Recruit and train team members
· Assign team members to tasks
· Coordinate activities of team members and subteams
· Assess project risks
· Monitor and control project deliverables and milestones
· Verify the quality of project deliverables
External Responsibilities of the Project Manager
· Report the project’s status and progress
· Establish good working relationships with those who identify the needed system requirements
· The people who will use the system
· Work directly with the client (the project’s sponsor) and other stakeholders
· Identify resource needs and obtain resources
Various Titles/Roles of Project Managers
Project Management Tasks
· Beginning of project
· Overall project planning
· During project
· Project execution management
· Project control management
· Project closeout
· Project management approach differs for
· Predictive SDLC
· Adaptive SDLC
·
System Development Life Cycle (SDLC)
· Project planning – initiate, ensure feasibility, plan schedule, obtain approval for project
· Analysis – understand business needs and processing requirements
· Design – define solution system based on requirements and analysis decisions
· Implementation – construct, test, train users, and install new system
· Support – keep system running and improve
Project Management Body of Knowledge
· Scope management
· Control functions included in system
· Control scope of work done by team
· Time management
· Build detailed schedule of all project tasks
· Monitor progress of project against milestones
· Cost management
· Calculate initial cost/benefit analysis
· Monitor expenses
Project Management Body of Knowledge (continued)
· Quality management
· Establish quality plan and control activities for each project phase
· Human resource management
· Recruit and hire project team members
· Train, motivate, team build
· Communications management
· Identify stakeholders and their communications
· Establish team communications
Project Management Body of Knowledge (continued)
· Risk management
· Identify and review risks for failure
· Develop plans to reduce these risks
· Procurement management
· Develop requests for proposals (RFPs)
· Evaluate bids, write contracts, monitor performance
· Integration management
Three Driving Forces to Start IS Project
· Respond to opportunity
· Top-down
· Resolve problem
· Bottom-up
· Conform to directive
· Legislative changes
So basically, in connection to what I have interviewed, he is a systems analyst of the Davao Light and Power Company. He stated that all of the jobs in their department is focused on supporting all the processes in their organization. They can suggest projects to the top management, but basically all projects are for fast processing to other departments and support type. So basically, they come up with projects but still they depend on the top management.
Appendixes:
References:
www.itk.ilstu.edu/.../Chapter%203%20-%20Analyst%20as%20a%20Project%20Manager.ppt
http://en.wikipedia.org/
Subscribe to:
Posts (Atom)
Playlist
