Juan or Pedro?

This was the scenario:

Consider the following dialogue between a systems professional, John Juan, and a manager of a department targeted for a new information system, Peter Pedro:

Juan: The way to go about the analysis is to first examine the old system, such as reviewing key documents and observing the workers perform their tasks. Then we can determine which aspects are working well and which should be preserved.

Pedro: We have been through these types of projects before and what always ends up happening is that we do not get the new system we are promised; we get a modified version of the old system.

Juan: Well, I can assure you that will not happen this time. We just want a thorough understanding of what is working well and what isn’t.

Pedro: I would feel much more comfortable if we first started with a list of our requirements. We should spend some time up-front determining exactly what we want the system to do for my department. Then you systems people can come in and determine what portions to salvage if you wish. Just don’t constrain us to the old system.

Required:

a. Obviously these two workers have different views on how the systems analysis phase should be conducted. Comment on whose position you sympathize with the most.

b. What method would you propose they take?

The question was about the two workers having different views on how the systems analysis phase should be conducted. And then comment on whose position you sympathize with the most. So to start, for me I will go on to Mr. Juan’s point of view in the analysis phase because if the management really wanted a new system, the workflow and all of the processes of the organization will also change. So they will start from the scratch. But still they will base their new system to the goals and objective of the organization. What I like about Mr. Juan’s point of view in the analysis phase is that their business has already been running and had already set the goals and objective of what their business will be. Shall we say we will propose a new system, a really new system and not a modified one, all of the workflow and processes of the business of the organization will be affected and will definitely not the same as before. So that is also a risk that will be taken to account. Before proposing a new system, this is what you need to do in order to have an effective proposal. First is, you must plan and analyze all the necessary information or data that is needed for the new system but you are inclined to the business goals and objective of an organization. I’m not against the idea of Mr. Pedro to propose a new system that is not modified old system, a really new system. He just needs to be sure and work out well all the needed information and data for the new system. Changing an old system to a new system is very risky and hard to do but if it is successful the benefits of the system will be definitely come to use. Planning out a new system but still turning into a modified one is not really bad it is just making things easier, for example the old system is already coming to its full capacity, meaning the memory is coming to its limits then maybe they can modify it to be more efficient in the next 10 years, if not 5 years. When you talk about having a new system you are also taking it to account its life span of service in order for it to be more efficient. Talking about proposing a new system there are risks that is involve so proper planning is needed. But maybe also in addition, if you want to propose a new system you could do these things, it my own idea, first is gather all the needed information, then list all the requirements needed for the new system, then plan it very well and evaluate. Maybe this will help. If things are settled apply those things that are still useful and those things that can be eliminated. But that is only an idea. But generally, with very well planned system is also a good alternative. As relation to God what had said that there is no perfect thing or creature in this world as same as to those systems, just proper development and maintenance in order to have an efficient and well generating system.

b. What method would you propose they take? Why?
So the method that I would propose to them that they will take is the method of a system development process? For me the method depends on what really the management wants in order to make the system. So what are the steps? There are steps in creating a system, so in order for them to develop a system they should follow some protocols in developing a system. So there are steps in developing a system, which is the planning, implementation, testing, documenting, deployment, and maintenance. So these are the steps in system development process. So first things first is what is its definition a software development process is a structure imposed on the development of a software product. Synonyms include software life cycle and software process. There are several models for such processes, each describing approaches to a variety of tasks or activities that take place during the process. The reason why I added the definition is that they can understand what my point is, or shall we say it is an overview in creating or developing a system. So to start, the first step you need to do is to plan; the important task in creating a software product is extracting the requirements or requirements analysis. Customers typically have an abstract idea of what they want as an end result, but not what software should do. Incomplete, ambiguous, or even contradictory requirements are recognized by skilled and experienced software engineers at this point. Frequently demonstrating live code may help reduce the risk that the requirements are incorrect. Once the general requirements are gleaned from the client, an analysis of the scope of the development should be determined and clearly stated. This is often called a scope document. Certain functionality may be out of scope of the project as a function of cost or as a result of unclear requirements at the start of development. If the development is done externally, this document can be considered a legal document so that if there are ever disputes, any ambiguity of what was promised to the client can be clarified. So planning is short for SPMP (Software Project Management Plan). SPMP is a technique in which making the planning phase feasible. As you acquired the SPMP that is the time you can proceed to the analysis phase. So part of this is step are the analysis phase in a system development. So the requirements on analysis phase are the SRS or (Software Requirements Specification). Here you are going to identify all the information that is going to be included in your system. An example would be the system features of your system, the functional and non-functional requirements of your system. So if you are done in doing the SRS the next thing you should do is design. So these are some of the things you need to do in order to attain what are the goals that are needed to be accomplished. So if you already finished planning on what are the things you need to do, then you can proceed to the next step which is implementation, testing and documenting. Implementation is the part of the process where software engineers actually program the code for the project. Software testing is an integral and important part of the software development process. This part of the process ensures that bugs are recognized as early as possible. Documenting the internal design of software for the purpose of future maintenance and enhancement is done throughout development. This may also include the authoring of an API, be it external or internal. Then, deployment starts after the code is appropriately tested, is approved for release and sold or otherwise distributed into a production environment. Software Training and Support is important because a large percentage of software projects fail because the developers fail to realize that it doesn't matter how much time and planning a development team puts into creating software if nobody in an organization ends up using it. People are often resistant to change and avoid venturing into an unfamiliar area, so as a part of the deployment phase, it is very important to have training classes for new clients of your software. Maintenance and enhancing software to cope with newly discovered problems or new requirements can take far more time than the initial development of the software. It may be necessary to add code that does not fit the original design to correct an unforeseen problem or it may be that a customer is requesting more functionality and code can be added to accommodate their requests. It is during this phase that customer calls come in and you see whether your testing was extensive enough to uncover the problems before customers do. If the labor cost of the maintenance phase exceeds 25% of the prior-phases' labor cost, then it is likely that the overall quality, of at least one prior phase, is poor. In that case, management should consider the option of rebuilding the system (or portions) before maintenance cost is out of control. Bug Tracking System tools are often deployed at this stage of the process to allow development teams to interface with customer/field teams testing the software to identify any real or perceived issues. These software tools, both open source and commercially licensed, provide a customizable process to acquire, review, acknowledge, and respond to reported issues. The other technique that is crucial in developing a system is that you need to identify your model. There are many examples of models such as waterfall, agile, and extreme programming. But also there are other model that is also needs to be considered. Iterative development prescribes the construction of initially small but ever larger portions of a software project to help all those involved to uncover important issues early before problems or faulty assumptions can lead to disaster. Iterative processes are preferred by commercial developers because it allows a potential of reaching the design goals of a customer who does not know how to define what they want. Agile software development processes are built on the foundation of iterative development. To that foundation they add a lighter, more people-centric viewpoint than traditional approaches. Agile processes use feedback, rather than planning, as their primary control mechanism. The feedback is driven by regular tests and releases of the evolving software. Extreme Programming (XP) is the best-known iterative process. In XP, the phases are carried out in extremely small (or "continuous") steps compared to the older, "batch" processes. The (intentionally incomplete) first pass through the steps might take a day or a week, rather than the months or years of each complete step in the Waterfall model. First, one writes automated tests, to provide concrete goals for development. Next is coding (by a pair of programmers), which is complete when all the tests pass, and the programmers can't think of any more tests that are needed. Design and architecture emerge out of refactoring, and come after coding. Design is done by the same people who do the coding. (Only the last feature — merging design and code — is common to all the other agile processes.) The incomplete but functional system is deployed or demonstrated for (some subset of) the users (at least one of which is on the development team). At this point, the practitioners start again on writing tests for the next most important part of the system. The waterfall model shows a process, where developers are to follow these steps in order:

1. Requirements specification (AKA Verification or Analysis)
2. Design
3. Construction (AKA implementation or coding)
4. Integration
5. Testing and debugging (AKA validation)
6. Installation (AKA deployment)
7. Maintenance

After each step is finished, the process proceeds to the next step, just as builders don't revise the foundation of a house after the framing has been erected.
There is a misconception that the process has no provision for correcting errors in early steps (for example, in the requirements). In fact, this is where the domain of requirements management comes in, which includes change control. The counter argument, by critics to the process, is the significantly increased cost in correcting problems through introduction of iterations. This is also the factor that extends delivery time and makes this process increasingly unpopular even in high risk projects. This approach is used in high risk projects, particularly large defense contracts. The problems in waterfall do not arise from "immature engineering practices, particularly in requirements analysis and requirements management." Often the supposed stages are part of review between customer and supplier; the supplier can, in fact, develop at risk and evolve the design but must sell off the design at a key milestone called Critical Design Review (CDR). This shifts engineering burdens from engineers to customers who may have other skills.

Other models

Capability Maturity Model Integration

The Capability Maturity Model Integration (CMMI) is one of the leading models and based on best practice. Independent assessments grade organizations on how well they follow their defined processes, not on the quality of those processes or the software produced. CMMI has replaced CMM.

ISO 9000

ISO 9000 describes standards for a formally organized process to manufacture a product and the methods of managing and monitoring progress. Although the standard was originally created for the manufacturing sector, ISO 9000 standards has been applied to software development as well. Like CMMI, certification with ISO 9000 does not guarantee the quality of the end result, only that formalized business processes have been followed.

ISO 15504

ISO 15504, also known as Software Process Improvement Capability Determination (SPICE), is a "framework for the assessment of software processes". This standard is aimed at setting out a clear model for process comparison. SPICE is used much like CMMI. It models processes to manage, control, guide and monitor software development. This model is then used to measure what a development organization or project team actually does during software development. This information is analyzed to identify weaknesses and drive improvement. It also identifies strengths that can be continued or integrated into common practice for that organization or team.

Formal methods

Formal methods are mathematical approaches to solving software (and hardware) problems at the requirements, specification and design levels. Examples of formal methods include the B-Method, Petri nets, Automated theorem proving, RAISE and VDM. Various formal specification notations are available, such as the Z notation. More generally, automata theory can be used to build up and validate application behavior by designing a system of finite state machines. Finite state machine (FSM) based methodologies allow executable software specification and by-passing of conventional coding (see virtual finite state machine or event driven finite state machine). Formal methods are most likely to be applied in avionics software, particularly where the software is safety critical. Software safety assurance standards, such as DO178B demand formal methods at the highest level of categorization (Level A). Formalization of software development is creeping in, in other places, with the application of Object Constraint Language (and specializations such as Java Modeling Language) and especially with Model-driven architecture allowing execution of designs, if not specifications. Another emerging trend in software development is to write a specification in some form of logic (usually a variation of FOL), and then to directly execute the logic as though it were a program. The OWL language, based on Description Logic, is an example. There is also work on mapping some version of English (or another natural language) automatically to and from logic, and executing the logic directly. Examples are Attempto Controlled English, and Internet Business Logic, which does not seek to control the vocabulary or syntax. A feature of systems that support bidirectional English-logic mapping and direct execution of the logic is that they can be made to explain their results, in English, at the business or scientific level.

The Government Accountability Office, in a 2003 report on one of the Federal Aviation Administration’s air traffic control modernization programs,[2] recommends following the agency’s guidance for managing major acquisition systems by

· Establishing, maintaining, and controlling an accurate, valid, and current performance measurement baseline, which would include negotiating all authorized, unpriced work within 3 months;
· Conducting an integrated baseline review of any major contract modifications within 6 months; and
· Preparing a rigorous life-cycle cost estimate, including a risk assessment, in accordance with the Acquisition System Toolset’s guidance and identifying the level of uncertainty inherent in the estimate.

So these are the methods that I would suggest or propose to them.

References:
Google.com
http://en.wikipedia.org/wiki/Software_development_process

Google?

What is Google?

Via John Battelle, Rick Skrentas remarkable piece on what Google have actually built. They don’t just have the world’s best search engine; they have the world’s largest and most scalable platform for developing huge web-based applications.

Google has taken the last 10 years of systems software research out of university labs, and built their own proprietary, production quality system. What is this platform that Google is building? It’s a distributed computing platform that can manage web-scale datasets on 100,000 node server clusters. It includes a petabyte, distributed, fault tolerant filesystem, distributed RPC code, and probably network shared memory and process migration. And a datacenter management system which lets a handful of ops engineers effectively runs 100,000 servers. Any of these projects could be the sole focus of a startup.

Who are Google’s Competitors?

These are some of Google’s adversary:

Yahoo! Inc.

MSN

AOL,

Disney Online

Match.com, LLC

Sina Corp.

Daum Communications Corp.

INFORMATION TECHNOLOGY AT GOOGLE

The focus of information technology at Google for both software and hardware is speed and cost.

These two metrics are valued more than any other criteria such as reliability of machines or high performance enterprise computing hardware. Ultimately, the result must transform a response time of user query using Google’s search engine to be completed within a one second time-frame. Started in Larry Page’s dormitory room, the information technology at Google has transformed into a full-blown large cluster PC network that functions similar to a computing grid. Even though information technology infrastructure has changed dramatically over the years, the model of IT use at Google has stayed the same. This model follows the original principles adopted by the co-founders of building a prototype system that uses commodity hardware and intelligent software. The shift of computer industry with PCs becoming commodity electronic hardware over the years has worked in favor of Google’s IT strategy in getting the best cost performance ratio (Patterson & Hennessy, 2004). Thus, instead of purchasing the latest microprocessors, Google IT performs calculations to look for the best value of processing power per dollar and purchasing many PCs that are only a few months old in the market, but at a much lower discounted price. This is suitable for Google because the framework of their search engine is built around parallelizing many user query requests across multiple machines and if more processing is required, the system can simply increase more machines to serve even greater user requests. The overall price per performance is more important than individual peak performances, and this enables Google to achieve superior speed at a fraction of the cost rather than using a few, but expensive high-end server systems. The end equation for Google’s IT in selecting machines is calculated by the cost per query, and is derived by the sum of capital expenses and operating costs divided by performance. For accuracy, the calculation takes into inherent effects due to hardware depreciation and maintenance repairs. At the data centers, the primary cost factor is capital expenditure credited to hardware, followed by personnel and hosting costs (Barozzo, et al., 2003).

What are the services that Google offer?

Key Product and Services

Online advertising is Google’s core product and accounts for 90% of the company’s revenue. AdWords, a cost-per-click pricing scheme, was a result of Google’s newly formed business Model in online advertising. AdWords allows advertisers to pay Google once visitors click on an Advertisement after entering a search query. Unlike other online marketing that use image and animated banners, these advertisements are text-based to maintain an uncluttered page design. This is a concept that Google’s co-founders believe is essential for an enjoyable user search engine experience since most users typically want to find information and promptly leave the search results page. Increasing the covered audience is a complementary product called AdSense which involves placing targeted AdWords advertisements on Google’s partner websites

Product/Service Name Description

Google Earth - Satellite imagery of geographical locations

Google Maps - View driving maps and directions

Google Local - Search for local businesses and shops

Google News - Search for news stories

Google Video - Search for TV programs and video clips

Google Desktop Search - Search for offline information stored on computers

Google Image Search - Search for images online

Google Sketch Up - 3D model design tool

Google Checkout - Online payment processing service

Google Search Appliance - Enterprise search engine

GMail - Web-based email client

GTalk - Internet instant messaging and VoIP

Orkut - Online social network community

Froogle - Electronic shopper product search

Others:

Google Page Creator, Google Analytics, Picasa, Blogger, Google Mobile, Google

SMS, Google Finance, Google Groups, Google Scholar, Google Pack, Google Book

Search, Google Code, Google Alerts, Google Calendar

What is Google’s unique advantage?

One thing that has become evident to me is that Google grows in an organic fashion, unlike any other company I know of. Google develops tools that are internally useful and then releases them to the world. Google does not develop products to sell to the world. Google does not have external contracts, at least in the traditional sense, as far as I can tell.

Let me elaborate on this. Google is obviously best known for search and for ads associated with search. This is in essence Google’s one true product. It is the one feature Google developed for the outside world. When Google developed search it was no different from a small company. It is what Google has done since then that makes Google different.

Google doesn’t answer to any external power. They don’t have anyone they have to deliver a product to. There is no contract with a deadline. Due to not having any external dependencies, Google can continuously iterate over a product until it reaches a state of near perfection. It can stay in internal testing as long as Google wants and no one is going to care. See Gmail, Google Maps, etc. This then allows Google to use the perfect form of the agile process. Continuous iterations and testing and development, continues improvement. Then as Google sees fit, release the products. As they get better and better, more people use them and more money from ads comes in. It’s beautiful.

It’s also unlikely any other company is going to be able to pull this off. Google hit on the formula for ads before anyone else. They now have such a commanding lead in that arena that to compete with them you need deep pockets of money of your own. That makes it difficult to launch a company and follow Google’s lead of avoiding external dependencies and having the near perfect product development process.

At this point, you might be screaming at me that I’m wrong, because Google does have external contracts, especially for serving up ads on other sites. But notice that Google’s contracts are different from most companies’ contracts. Google isn’t developing a product for these companies. All they are doing is giving them an existing product that Google has already completed and released. Development on that product might still be happening, but it happens within Google, not within the realms of the contract. Google is still free to develop how ever they want.

For almost everyone else, you’re going to have to create a product and then drive sales of that product or else sign a contract and then deliver a custom product to the customer. You’ll have external dependencies that will force an outside reality upon you that Google simply doesn’t have. You can argue that Google is dependent upon ads, but at this point Google has captured such a large share of that market and is steadily capturing more of it, that it really isn’t a dependency for Google. Sure, Google should probably diversify; just in case the ad market tanks, but at this point Google has so much money they can afford to take their time.

Global Expansion

The international markets are critical for many technology companies in expanding new business opportunities and generating more revenues. Similarly, this principle is reminiscent in Google’s case, as the international markets contribute from 30% to 40% of the company’s total revenues every quarter for the past two years.4 In order to tap into the international market, Google’s search engine has been translated to allow multi-language search capabilities, while maintaining its philosophy of objective and unbiased search results (Brin, 2001). The strong international markets for Google include the United Kingdom, Western Europe, Japan, Canada, and Australia. Google has transformed from a start-up firm to a multi-national corporation; however, the majority of its employees are still based in the Mountain View headquarters. Google has international presence in all continents of the world other than Africa and Antarctica. However, the location of its international employee base is divided into two primary groups: engineering and product development team, and a sales force team. Google offers customer interfaces in over 40 different languages and close to 50 different currency exchanges to date.

Conclusion

In only a short period of time, Google has become a dominant player in search technology and a formidable threat to many other technology firms in various industry sectors including advertising, standard software, web application development, and telecommunication networks. Behind the scenes, the use of information technology has been strategic and critical for Google’s search engine success and other Google products and services. A variety of advanced concepts in computer science have been applied to many of Google’s products and services ranging from topics in distributed systems, machine learning, software architecture, and communications networks. Google’s vision of applying advanced computing concepts and innovative ideas has allowed the company to stay as a forefront leader. However, there are even greater challenges for Google as it matures into a multi-national corporation. How will Google be able to enter international markets where information dissemination is highly regulated and controlled by the foreign governments? Can Google continue to sustain its rapid growth while continue to hold on its unique work culture? With the massive amount of information collected on a daily basis, will Google invade privacy concerns? Will Google be able to maintain its technology leadership as competition gets even more intense? And how real is the threat from Microsoft as it claims to defend itself and compete rigorously with Google in the search market? The story behind Google is only a start. Only time will tell Google’s destiny. Many futurists predict that Google may perhaps become the most important technology company this decade, similar to how Microsoft and Intel have changed the technology industry in the past.

References:

Google.com

Assignment 5 in SAD

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/

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.

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 Without large-scale capital investment Without radical change to company standards
Alternatives	Possible ways to achieve the objectives	Reuse existing certified software Introduce formal specification and verification Invest in testing and validation tools
Risks	Potential risks for this phase	No cost effective quality improvement possible Quality improvements may increase costs excessively New methods might cause existing staff to leave
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 Limited tool support available for company standard development system Reusable components available but little reuse tool support
Plans	Development plans for the next phase	Explore reuse option in more detail Develop prototype reuse support tools Explore component certification scheme
Commitment	Resources needed to achieve the plans	Fund further 18-month study phase

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