IS Professional and users frustrations

What are the two most frequently experienced causes of frustration of IS professionals and users while working on an IS plan?

In every organization or business transactions, one individual could never avoid the fact that any project it not always lead to achievement of the plan. Since, they are working with an Information System Plan, a strategic planning must be consider.

Strategic planning is an organization's process of defining its strategy, or direction, and making decisions on allocating its resources to pursue this strategy, including its capital and people. Various business analysis techniques can be used in strategic planning, including SWOT analysis (Strengths, Weaknesses, Opportunities, and Threats ) and PEST analysis (Political, Economic, Social, and Technological analysis) or STEER analysis involving Socio-cultural, Technological, Economic, Ecological, and Regulatory factors. According to other source, strategic plan is a document used by an organization to align its organization and budget structure with organizational priorities, missions, and objectives. It is also a process of comprehensive, integrative program planning that considers, at a minimum, the future of current decisions, overall policy, organizational development, and links to operational plans. . A satisfactory strategic plan must be realistic and attainable so as to allow managers and entrepreneurs to think strategically and act operationally. In align with that, strategic plan must be reliable and suitable for the need of the company.

In doing a strategic plan, it is not really known to everyone that there are frustrations that may trigger. Frustrations in a way that it may cause depression and stress to the professionals and users that are doing it. In doing an Information Strategic plan, it is really a must that the user and the professionals doing it must first determine the company’s background and other facts and information that can help and then again be a useful tool for the planning.

Like in the situation of any IS professional, the Systems Analyst/Software Engineers which always consider their clients with systems that they are working on. Seldom it is being denied by the involve parties, that the systems they are developing, least on what they are expecting will lead to failure. Thus, giving frustrations to the Systems Analyst/ Software Engineers itself and especially to the users.

In today's increasingly competitive marketplace, an organization can't afford to fall short in strategic decision-making or execution. But, finding out where and why efforts are falling short can be tricky.

Organizational frustration has been defined by Paul Spector in a very similar fashion, and refers to an interference with goal attainment or maintenance that is caused by some stimulus condition within the organization (Spector, 1978). It has been further narrowed to be defined as the interference with an individual’s ability to carry out their day to day duties effectively (Keenan & Newton, 1984). The sources of organizationalfrustration put forth by Spector include the physical environment (both natural and man-made), the organizational structure and climate, the rules and procedures of the organization, and individuals both in and out of the organization. In addition, the concept of situational constraints (Peters & O'Connor, 1980) has been hypothesized to contribute to organizational frustration (Storms & Spector, 1987). Spector (1978) suggested four reactions to organizational frustration: 1) an emotional response of anger and increased physiological arousal, 2) trying alternative courses of action, 3) aggression, and 4) withdrawal. Of the behavioral reactions, only the second one – that of trying alternative courses of action to obtain the goal – is an adaptive response, while the other three are maladaptive. It is likely that the emotional reaction accompanies one of the three behavioral reactions, although the emotional reaction may be maladaptive by itself and become a further impediment to goal attainment. Clearly, should an individual become frustrated, it is in the best interests of the organization to have the individual respond in an adaptive way and attempt to find another solution to the problem in a clear decisive manner. Spector also put forth the idea that some mild forms of frustration may be seen as challenges rather than problems for some individuals, thus causing a motivational effect rather than a hindering effect and increasing the likelihood of an adaptive response rather than a maladaptive one.

Frustration with technology is a major reason why people cannot use computers to reach their goal, hesitate to use computers, or avoid computers altogether. A recent study from the Pew Internet and American Life study found that a large percentage of people never go online, because they find the technology to be too frustrating and overwhelming (Pew, 2003). Currently, 42% of Americans do not use the Internet, in large part because they find it to be frustrating and confusing. This is not surprising; previous research on user frustration found that users wasted nearly one-third to one-half of the time spent on the computer, due to frustrating experiences (Bessiere, 2002; Bessiere, Lazar, Ceaparu, Robinson, & Shneiderman, 2003).

Unfortunately, computer applications are often designed with interfaces that are hard to use, and features that are hard to find. Even government web sites, which are supposed to provide easy access to government information for all citizens, are frequently hard to use and produce high levels of user frustration (Ceaparu, 2003). Frustration with technology can lead to wasted time, changed mood, and affected interaction with colleagues. When users in a workplace are frustrated with their computers, it can lead to lower levels of job satisfaction (Murrell & Sprinkle, 1993). In some cases, user frustration with technology can even lead to increased blood volume pressure and muscle tension (Riseberg, Klein, Fernandez, & Picard, 1998)

Research on computer frustration has shown that that computer self-efficacy and attitudes play a significant role in reducing the frustration levels in computing. Level of comfort with the computer and the determination to fix a problem, which are associated with a high level of computer self efficacy, both appear as important factors in both the immediate experience of frustration as well as the overall frustration level after a session of computer use. In the previous study on computer frustration, computer attitude variables mediated the experience of frustration but experience did not. Simply using a computer, therefore, does not lessen user frustration; rather it is one’s attitude towards it and comfort with it.

Computers can be valuable tools, and networked resources via the Internet can be beneficial to many different populations and communities. Unfortunately, when people are unable to reach their task goals due to frustrating experiences, this can hinder the effectiveness of technology.

Computing systems this era raises high in a short period of time. Though our country is a 5 year behind than those countries abroad, still using internet is a common tool for someone like in communications. And more likely in a business, it is also a trend of using internet and intranet in their operations since it can help progress their company. Now a day, an even small scale business also acquires using internet and computers for their daily routine. That is because it can help them improve their skills and at the same time it can lessen the work load since using computers doesn’t requires much time.

Some organizations, are simply better than most at producing results. Likely, they have learned to address frustrations, any one of which is capable of stymieing the effectiveness of the organization. It maybe they are not performing their duties well. Besides, the execution of their strategic plan may be lacking. There could also be business results that are not optimal.

Strategic execution is a difficult discipline for any organization. They might say that "We don't need more knowing; we need more doing." This usually leads to frustration; a feeling that your annual strategic planning process is ineffective. And in the end resulting to disappointment with the lack of action, traction, and results from your strategic planning efforts.

Improving business results is the primary reason for engaging in strategic planning, yet in many organizations, this common exercise feels like an exercise in futility. Initially, holding a strategic planning session brings the executive team together by stimulating a lot of good conversation and new ideas. This feels good at the time, but unfortunately, it's usually nothing more than a temporary "sugar buzz." Once the session is over and the enthusiasm begins to fade, each team member returns to the status quo. They quickly get pulled back into tactical fire fighting, focusing their attention on their own department needs rather than the organizational plans agreed to in the planning session. Without clear, consistent action on shared initiatives, the entire organization struggles to establish any kind of momentum.

Basically, we could never say or predict what will happen in every system that will be developing by any Systems Analyst/Software Engineers and so on throughout their job. To have a touch of reality here, we have interviewed an IS professional on what did he thinks the two most frequently experienced causes of frustration of IS professionals and users while working on an IS plan.

According to him the following could be considered as the usual frustrations any IS professional and users may encounter during an IS Plan.

· Budget

A budget is one of those pivotal tools that is used across many departments within a company. For the developers, it dictates how much time to spend on specific areas of the application. For the project manager, it's a baseline used to determine whether the project is on track. For sales or the client, it correlates directly to the success of the effort. It's no surprise that one of the biggest issues in creating a budget is interpretation.

Based on their organization, there are certain situation that the budget for a particular project is not properly allocated. Thus, giving a perspective for them on not continuing the project since they have given limited resources and eventually could make the project fail. This is really a frustration to the Software developer’s side especially if the system is already in the process of User Acceptance Test. It is already hard for them to continue for they have insufficient funds.

Regardless of how close you come to reality, a client will be much happier if your project comes in below budget than over it; however, too high a risk value can create sticker shock, revealing inexperience and creating misgivings about your management abilities. By following the guidelines we've suggested and applying some common sense, you can be assured that your team, project drivers, and client will enjoy the benefits of a well-estimated project.

At the same time the user will be more frustrated because the deliverables are not being given to them properly and on time. The time problem could also be included in this frustration for if less budget is allocated to a certain project, there will be a tendency for the developer to cram if it already in the period of presenting it to its client. As I have said, the users are expecting for the said project to be deliver on that time then because of some delays, the developers tend to commit mistakes and in the end, ensuing to a project failure. And another big cost is at stake for this letdown.

· Well-Structured design

Another would be this one, according to him, the design of a certain system should be in a manner of a well-structured design so that in a middle of any software development the client would not always complain. Because for them, the users have the tendency of adding up enhancements to their system. Suggesting new additional features, hence, the system will be prone to bugs. It would be a great frustration for the developers because they could not easily perfect the system for the complaints of the client can give to them. Also, in the user’s side, it would be a frustration for the slow productivity the developer could have give to them.

Both on the users and developers are the frustrations could been experiences. Since they are both involved in the Information System Plan, they cannot avoid these certain things. For the developers, it is very frustrating for not giving the proper service to their clients and not offering the satisfaction the users should also accept. It is just so sad to hear that these frustration are being encountered also because of the developer or the user either. For the reason that every success of a system comes from the cooperation of the involve people. Not to play as the worsening effect to any developer or a user instead.

References:

http://www.allbusiness.com/human-resources/workforce-management-hiring-consulting/872033-1.html

http://www.stanford.edu/group/siqss/itandsociety/v01i03/v01i03a02.pdf

to our interviewee from Davao Light and Power Company

University Life Cycle

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?

Every organization have establish a life cycle to follow in order to manage and supervise every transactions its organization processes. Let us consider our own, the University of Southeastern Philippines. The organizational life cycle would be the life cycle of an organization from birth level to the termination. There are many stages that should be consider in administering the University itself. At the foundation of effective management for any organization is the fundamental truth that all

organizations, like any living organisms, have a lifecycle and undergo very predictable and repetitive patterns of behavior as they grow and develop. At each new stage of development an organization is faced with a unique set of challenges. How well or poorly management addresses these challenges, and leads a healthy transition from one stage to the next, has a significant impact on the success or failure of their organization. Organizations go through different phases of growth. The first challenge for leaders who wish to grow their organizations is to understand what phase of the organizational life cycle one is in.

Different experts will argue on how many phases there are, but there is elegance in using something easy to remember. Many are saying that the organizational life cycle is divided into phases. From Startup. (or Birth), Growth, Decline. When in decline, an organization will either undergo renewal or death. Each of these phases present different management and leadership challenges that one must deal with.

As Henry ford says, “Getting ready is secret to success”. Basically our University have set plans to start the organization, not just to establish foundation but also through the phase of making the organization grow. These is the stage where an organization should expects to see revenues climb, new services and products developed, more employees hired and so on. We could also see the decline phase as part of the organizational cycle. This is sometimes encountered when there is a transformation development involve in the University’s processes. One example would be the sudden change of the Enrollment Information System used by the University. Because we can never assure that all will easily adopt we this unexpected decision of the Administration. The involve people have the tendency to resist with this transformations. So in result, the new products will not boost because of the less support given by the people. Fortunately, the University is doing good with the newly Student Registration Management Information System (SRMIS) and in the stage of satisfying the customers’ needs.

We can say that any organization could not have decide to follow any life cycle without any basis or guide to success. Below is the Vision and Mission of the University of Southeastern Philippines.

Vision

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.

From the presented Vision of the University, it’s obvious that the Administration have been working out to achieve its dream for the betterment and improvement of the University. As it aims to be a premier University in the ASEAN Region, the University is now developing and building up proper procedures that could made University of Southeastern Philippines to be the top of all. Also, this could serve as a foundation of establishing a sanctuary of excellence and development toward our Region. With all the different events and projects the University have been pursuing and implementing, I think they have given every people involve in its organization a reason to cooperate and believe that they are really doing all these things for the sake of the University.

The following are just the living evidences to ensure that the University of Southeastern Philippines will become the home of quality and improvement across all nations.

USeP-DOST AFNR PROJECT

Accelerated Teacher Education Program

Comprehensive Irrigation Research & Development Umbrella Program

Continuing Professional Development

Expanded Tertiary Education Equivalency and Accreditaion Program

Institute of Languages

Knowledge for Development Center in Davao

Lifelong Study Center

Mindanao E-Learning Space

Mindanao Center for Policy & Development Studies

Mindanao Center for Technical Education & Staff Development

Mt. Malindang Biodiversity Research Programme

Pamulaan Center for Indigenous Peoples Education

Southern Mindanao Agriculture & Resources Research & Development Consortium

Teacher Training Center for Mindanao

University Guidance and Testing Office

World Bank - Knowledge for Development Center

Zonal Computerization Center Eastern Mindanao

These University’s Centers are in strive to serve its people in the way that all will be satisfied. These will enhance the capability of the institution through curricular program innovations, facilities and manpower upgrading, and enterprise development projects that provide students with adequate training and education. Through this institutional capability enhancement project, the University will contribute its share in enhancing the demand by raising the quality of graduates with industry-desired skills, competencies and attitudes as workers and leaders in the competitive labor market and the progressive entrepreneurial world.

There are also programs that envisions to mainstream not only the graduates but also the teachers which is the Accelerated Teacher Education Program (ATEP). ATEP builds on the existing knowledge and skills in Islamic education and teaching experience in the Madrasah of madaris teachers. It evaluates and accredits prior learning and experience of the Asatidz, and allows them to upgrade their professional qualification while maintaining their teaching job in the public school or pilot private madaris.

Let us admit that because of the fast-changing of our environment, our University is in the stage of becoming a responsive and adoptive organization to all these transformations.

One program that is being implemented now is the Lifelong Study Center (LSC). The institutionalization of a Lifelong Study Center (LSC) is a policy response to change and globalization. In the present knowledge-based economy that characterizes the world, it is meant to sustain economic growth with more and better jobs and greater social cohesion in this part of the country. Lifelong learning, which is the characteristic of the LSC, is considered not only central to competitiveness and employability; it is also central to social inclusion, active citizenship and personal development.

Lifelong learning encompasses learning for personal, civic and social purposes as well as for employment-related purposes. It takes place in a variety of environments in and outside the formal education and training systems. It implies raising investments in people and knowledge; promoting the acquisition of basic skills, including digital literacy; and broadening opportunities for innovative, more flexible forms of learning. It transforms formal education and training systems in order to break down barriers between different forms of learning. It connotes a shift in our thinking of the fundamental organizational unit of education from the SCHOOL to the LEARNER.

Mission

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.

Based on the presented Vision and Mission, we could see that our University is really aspiring for a better organization in the future not only in Mindanao but also in the whole Philippines and of course globally.

Leading an organization through lifecycle transitions is not easy, or obvious. The same methods

that produce success in one stage can create failure in the next. Fundamental changes in leadership and management are all required, with an approach that delicately balances the amount of control and flexibility needed for each stage. Leaders who fail to understand what is needed (and not needed) can inhibit the development of their companies or plunge them into premature aging. The challenges that every organization must overcome at each stage of development first manifest themselves as problems that arise from the growth and success of the company and from external changes in markets, competitors, technology and the general business and political environment.

Thus, any organization cannot avoid the problems will be arising throughout its years of service. Problems are normal and desirable. Problems are the natural result of change. The only place on the lifecycle of an organization where there are no problems is the place where there is no change, which is Death. Your reward for successfully resolving the problems that confront you today, is a set of new problems tomorrow that will be larger and more complex. If your organization faces a high rate of change in your markets, technology or industry, your challenge is magnified. The faster the rate of change, the faster problems appear and grow.

That is why the University’s Administration is not only working alone, but as a whole team. Thus, making the University as a leading university in the country that promotes modernization and applies knowledge to create value towards social, economic, and technological developments.

You can drive your organization faster when you know the road ahead. Most of the issues you face are common to all organizations. There is no need for you to reinvent the wheel.

Organizations go through different life-cycles just like people do. Over time, they develop a certain kind of wisdom that sees them through many of the challenges in life and work. The University have gone to various planning stage, testing and later on the level of maintaining all the things that they have developed. Not all plans would result to success, so the University in certain times have to evaluate itself also. Because of this 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.

Since we can see changes from all the products that our University has offer to us for the past years, I think these have proved that the University truly follow a life cycle as a guide for its Vision and Mission. I guess, from this time on, the University have that understanding that gives them a sense of perspective and helps them to decide how to respond to decisions and problems in the workplace that they will be encountering in the future. And all the programs and projects that have been implemented had gone to a cycle of methodologies in order to reach its goal towards success.

References:

http://managementhelp.org/org_thry/org_cycl.htm

http://managementhelp.org/grow_biz/grow_biz.htm#anchor581127

http://www.usep.edu.ph

Systems Development Model

PROCESS MODELS

The System Development Life Cycle (SDLC) process applies to information system development projects ensuring that all functional and user requirements and agency strategic goals and objectives are met. The SDLC provides a structured and standardized process for all phases of any system development effort. These phases track the development of a system through several development stages from feasibility analysis, system planning and concept development; to acquisition and requirements definition; design; development; integration and testing; deployment and acceptance; though deployment and production; and finally to system retirement.

The systems development life cycle (SDLC) is a conceptual model used in project management that describes the stages involved in an information system development project, from an initial feasibility study through maintenance of the completed application.

Various Systems Development Life Cycle methodologies have been developed to guide the processes involved, and these are the Software Process Models.

According to Kerem Kosaner (2008), Process models are processes of the same nature that are classified together into a model. Thus, a process model is a description of a process at the type level. Since the process model is at the type level, a process is an instantiation of it. The same process model is used repeatedly for the development of many applications and thus, has many instantiations. One possible use of a process model is to prescribe how things must/should/could is done in contrast to the process itself which is really what happens. A process model is roughly an anticipation of what the process will look like. What the process shall be will be determined during actual system development.

A software process model is a development strategy that incorporates the development process, methods and tools used to design software. It is chosen based on the nature of the software and the methods and tools used in development. It often represent a networked sequence of activities, objects, transformations, and events that embody strategies for accomplishing software evolution. Such models can be used to develop more precise and formalized descriptions of software life cycle activities. A software process model is an abstract representation of a process. It presents a description of a process from some particular perspective.

These software models are classified as the traditional process models and the process models in recent times. There are many to mention software process models. So let me identify and discuss at least three of the systems development model.

The waterfall modelThe waterfall model is a popular version of the systems development life cycle model for software engineering. Often considered the classic approach to the systems development life cycle, the waterfall model describes a development method that is linear and sequential. Waterfall development has distinct goals for each phase of development. Imagine a waterfall on the cliff of a steep mountain. Once the water has flowed over the edge of the cliff and has begun its journey down the side of the mountain, it cannot turn back. It is the same with waterfall development. Once a phase of development is completed, the development proceeds to the next phase and there is no turning back.

Waterfall model phases

Requirements analysis and definition

What is a requirement?

It may range from a high-level abstract statement of a service or of a system constraint to a detailed mathematical functional specification. This is inevitable as requirements may serve a dual function and it may be the basis for a bid for a contract - therefore must be open to interpretation. Also may be the basis for the contract itself - therefore must be defined in detail. Both these statements may be called as a requirement.

Requirements definition: A statement in natural language plus diagrams of the services the system provides and its operational constraints. Written for customers

Requirements specification: A structured document setting out detailed descriptions of the system services. Written as a contract between client and contractor

Software specification: A detailed software description which can serve as a basis for a design or implementation. Written for developers

In this phase, establishing what the customer requires from a software system must the main concern. It is necessary to remember first the requirements needed in a systems development life cycle. The problem is specified along with the desired service objectives (goals) and the constraints are being identified.

System and software design

In System Analysis and Design phase, the whole software development process, the overall software structure and its outlay are defined. In case of the client/server processing technology, the number of tiers required for the package architecture, the database design, the data structure design etc are all defined in this phase. After designing part a software development model is created. Analysis and Design are very important in the whole development cycle process. Any fault in the design phase could be very expensive to solve in the software development process. In this phase, the logical system of the product is developed. Software Requirement Analysis is also known as feasibility study. In this requirement analysis phase, the development team visits the customer and studies their system requirement. They examine the need for possible software automation in the given software system. After feasibility study, the development team provides a document that holds the different specific recommendations for the candidate system. It also consists of personnel assignments, costs of the system, project schedule and target dates.

The requirements analysis and information gathering process is intensified and focused specially on software. To understand what type of the programs to be built, the system analyst must study the information domain for the software as well as understand required function, behaviour, performance and interfacing. The main purpose of requirement analysis phase is to find the need and to define the problem that needs to be solved.

In the system and software design phase, the system specifications are translated into a software representation. The software engineer at this stage is concerned with Data structure, Software architecture, Algorithmic detail and Interface representations.

The hardware requirements are also determined at this stage along with a picture of the overall system architecture. By the end of this stage the software engineer should be able to identify the relationship between the hardware, software and the associated interfaces. Any faults in the specification should ideally not be passed ‘down stream. It is the level of deriving a solution which satisfies software requirements.

Implementation and unit testing

In the implementation and testing phase stage the designs are translated into the software domain into a detailed documentation from the design phase can significantly reduce the coding effort. Testing at this stage focuses on making sure that any errors are identified and that the software meets its required specification. After code generation phase the software program testing begins. Different testing methods are available to detect the bugs that were committed during the previous phases. A number of testing tools and methods are already available for testing purpose.

Integration and system testing

In the integration and system testing phase all the program units are integrated and tested to ensure that the complete system meets the software requirements. After this stage the software is delivered to the customer [Deliverable – The software product is delivered to the. In integration and system testing, the design must be decoded into a machine-readable form. If the design of software product is done in a detailed manner, code generation can be achieved without much complication. For generation of code, Programming tools like Compilers, Interpreters, and Debuggers are used. For coding purpose different high level programming languages like C, C++, Pascal and Java are used. The right programming language is chosen according to the type of application.

Operation and maintenance

The maintenance phase is usually the longest stage of the software. In this phase the software is updated to meet the changing customer needs, adapted to accommodate changes in the external environment, correct errors and oversights previously undetected in the testing phases and enhancing the efficiency of the software. Software will definitely go through change once when it is delivered to the customer. There are large numbers of reasons for the change. Change could happen due to some unpredicted input values into the system. In addition to this the changes in the system directly have an effect on the software operations. The software should be implemented to accommodate changes that could be happen during the post development period.

The waterfall model maintains that one should move to a phase only when its preceding phase is completed and perfected. Phases of development in the waterfall model are thus discrete, and there is no jumping back and forth or overlap between them

As many find this approach particularly rigid, modifications have been made over the years and new variants of the model have emerged

The drawback of the waterfall model is the difficulty of accommodating change after the process is underway.

The advantage of waterfall development is that it allows for departmentalization and managerial control. A schedule can be set with deadlines for each stage of development and a product can proceed through the development process like a car in a carwash, and theoretically, be delivered on time. Development moves from concept, through design, implementation, testing, installation, troubleshooting, and ends up at operation and maintenance. Each phase of development proceeds in strict order, without any overlapping or iterative steps.

The disadvantage of waterfall development is that it does not allow for much reflection or revision. Once an application is in the testing stage, it is very difficult to go back and change something that was not well-thought out in the concept stage. Alternatives to the waterfall model include joint application development (JAD), rapid application development (RAD), synch and stabilize, build and fix, and the spiral model. The waterfall model however is argued by many to be a bad idea in practice, mainly because of their belief that it is impossible to get one phase of a software product's lifecycle "perfected" before moving on to the next phases and learning from them. A typical problem is when requirements change midway through, resulting in a lot of time and effort being invalidated due to the "Big Design Up Front"

IIn summary, the criticisms of a non-iterative development approach (such as the waterfall model) are as follows:

Poor flexibility; the majority of software is written as part of a contract with a client, and clients are notorious for changing their stated requirements. Thus the software project must be adaptable, and spending considerable effort in design and implementation based on the idea that requirements will never change is neither adaptable nor realistic in these cases.

Unless those who specify requirements and those who design the software system in question are highly competent, it is difficult to know exactly what is needed in each phase of the software process before some time is spent in the phase "following" it.

Constant testing from the design, implementation and verification phases is required to validate the phases preceding them. Users of the waterfall model may argue that if designers follow a disciplined process and do not make mistakes that there is no need to constantly validate the preceding phases.

Frequent incremental builds (following the "release early, release often" philosophy) are often needed to build confidence for a software production team and their client.

It is difficult to estimate time and cost for each phase of the development process.

The waterfall model brings no formal means of exercising management control over a project and planning control and risk management are not covered within the model itself.

Only a certain number of team members will be qualified for each phase, which can lead at times to some team members being inactive.

Prototyping Model

An easily modified and extensible model (representation, simulation or demonstration) of planned software system, likely including its interface and input/output functionality

The main focus of this model is to develop a prototype of the software. The client then evaluates the working prototype, and suggests improvements and corrections, which all go into developing the real application.

The prototyping model is used when the client is unsure about the exact specification but has a genuine need. Then the software engineers can develop a rough prototype to gain an approval of the customer. If the prototype developed is a working model, the developers may use code fragments of the prototype when developing the final application.

Of course, the developers must resist the temptation to extend a prototype into a full fledged application. Because if this is done, the quality will suffer in the long run. The prototype is only meant for evaluation purposes. Some code fragments may be used, but using the whole prototype is not generally a good idea.

The goal of prototyping based development is to counter the first two limitations of the waterfall model discussed earlier. The basic idea here is that instead of freezing the requirements before a design or coding can proceed, a throwaway prototype is built to understand the requirements. This prototype is developed based on the currently known requirements. Development of the prototype obviously undergoes design, coding and testing. But each of these phases is not done very formally or thoroughly. By using this prototype, the client can get an "actual feel" of the system, since the interactions with prototype can enable the client to better understand the requirements of the desired system.

Prototyping is an attractive idea for complicated and large systems for which there is no manual process or existing system to help determining the requirements. In such situations letting the client "plan" with the prototype provides invaluable and intangible inputs which helps in determining the requirements for the system. It is also an effective method to demonstrate the feasibility of a certain approach. This might be needed for novel systems where it is not clear that constraints can be met or that algorithms can be developed to implement the requirements.

• gather requirements
• developer & customer define overall objectives, identify areas needing more investigation – risky requiremnets
• quick design focusing on what will be visible to user – input & output formats
• use existing program fragments, program generators to throw together working version prototype evaluated and requirements refined

There are several steps in the Prototyping Model:

The requirements are being gathered for new system requirements are defined in as much detail as possible. This usually involves interviewing a number of users representing all the departments or aspects of the existing system.

A preliminary design is created for the new system.

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.

The users thoroughly evaluate the first prototype, noting its strengths and weaknesses, what needs to be added, and what should to be removed. The developer collects and analyzes the remarks from the users.

The first prototype is modified, based on the comments supplied by the users, and a second prototype of the new system is constructed.

The second prototype is evaluated in the same manner as was the first prototype.

The preceding steps are iterated as many times as necessary, until the users are satisfied that the prototype represents the final product desired.

The final system is constructed, based on the final prototype.

The final system is thoroughly evaluated and tested. Routine maintenance is carried out on a continuing basis to prevent large-scale failures and to minimize downtime.

The process iterated until customer & developer satisfied

• then throw away prototype and rebuild system to high quality

• alternatively can have evolutionary prototyping – start with well understood requirements.

Advantages of Prototyping

Users are actively involved in the development. It provides a better system to users, as users have natural tendency to change their mind in specifying requirements and this method of developing systems supports this user tendency.

Since in this methodology a working model of the system is provided, the users get a better understanding of the system being developed.

• Errors can be detected much earlier as the system is mode side by side.
• Quicker user feedback is available leading to better solutions.

Disadvantages

Leads to implementing and then repairing way of building systems.

Practically, this methodology may increase the complexity of the system as scope of the system may expand beyond original plans.

customer may want to hang onto first version, may want a few fixes rather than rebuild. First version will have compromises

developer may make implementation compromises to get prototype working quickly. Later on developer may become comfortable with compromises and forget why they are inappropriate.

customer may want to hang onto first version, may want a few fixes rather than rebuild. First version will have compromises

developer may make implementation compromises to get prototype working quickly. Later on developer may become comfortable with compromises and forget why they are inappropriate.

And last systems development life cycle would be the, The Capability Maturity Model (CMM) is a methodology used to develop and refine an organization's software development process. The model describes a five-level evolutionary path of increasingly organized and systematically more mature processes. CMM was developed and is promoted by the Software Engineering Institute (SEI), a research and development center sponsored by the U.S. Department of Defense (DoD). SEI was founded in 1984 to address software engineering issues and, in a broad sense, to advance software engineering methodologies. More specifically, SEI was established to optimize the process of developing, acquiring, and maintaining heavily software-reliant systems for the DoD. Because the processes involved are equally applicable to the software industry as a whole, SEI advocates industry-wide adoption of the CMM.

The CMM is similar to ISO 9001, one of the ISO 9000 series of standards specified by the International Organization for Standardization (ISO). The ISO 9000 standards specify an effective quality system for manufacturing and service industries; ISO 9001 deals specifically with software development and maintenance. The main difference between the two systems lies in their respective purposes: ISO 9001 specifies a minimal acceptable quality level for software processes, while the CMM establishes a framework for continuous process improvement and is more explicit than the ISO standard in defining the means to be employed to that end.

CMM's Five Maturity Levels of Software Processes

At the initial level, processes are disorganized, even chaotic. Success is likely to depend on individual efforts, and is not considered to be repeatable, because processes would not be sufficiently defined and documented to allow them to be replicated.

At the repeatable level, basic project management techniques are established, and successes could be repeated, because the requisite processes would have been made established, defined, and documented.

At the defined level, an organization has developed its own standard software process through greater attention to documentation, standardization, and integration.

At the managed level, an organization monitors and controls its own processes through data collection and analysis.

At the optimizing level, processes are constantly being improved through monitoring feedback from current processes and introducing innovative processes to better serve the organization's particular needs.

The Software development Life Cycle models could control, monitor large projects, can evaluate costs and completion targets, well defined user input, have ease of maintenance, there are standards in development and design. Nevertheless, it increased development time and cost, the systems used these models must be defined up front, user input is sometimes limited and it is really hard to estimate costs and sometimes project overruns.

At one time the model was beneficial mostly to the world of automating activities that were assigned to clerks and accountants. However, the world of technological evolution is demanding that systems have a greater functionality that would assist help desk technicians/administrators or information technology specialists/analysts.

References:

http://www.selectbs.com/adt/analysis-and-design/what-is-the-waterfall-model

http://searchcio-midmarket.techtarget.com/sDefinition/0,,sid183_gci755441,00.html

http://www.e-digg.com/services/software/sdlc-life-cycle.html

Kerem Kosaner (2008), Software Engineering.

http://www.Process Modeling Definition « Software Engineering.htm