Software Processing Methodology

Software Processing Methodology:

Understanding the Problem

Candidate

University

Advisor

Contents

TOC o “1-3” h z u Section I: PAGEREF _Toc280689991 h 5Introduction PAGEREF _Toc280689992 h 5Technical question PAGEREF _Toc280689993 h 6Motivation PAGEREF _Toc280689994 h 7Methodology PAGEREF _Toc280689995 h 7Research and Contribution Methods PAGEREF _Toc280689996 h 8Section II: PAGEREF _Toc280689997 h 10Software Processing Methodologies PAGEREF _Toc280689998 h 10Waterfall Methodology PAGEREF _Toc280689999 h 10Strengths PAGEREF _Toc280690000 h 11Weaknesses PAGEREF _Toc280690001 h 12Opportunity PAGEREF _Toc280690002 h 13Threats PAGEREF _Toc280690003 h 13Iterative Methodology PAGEREF _Toc280690004 h 14Strengths PAGEREF _Toc280690005 h 16Weaknesses PAGEREF _Toc280690006 h 17Opportunities PAGEREF _Toc280690007 h 18Threats PAGEREF _Toc280690008 h 20V-Model Methodology PAGEREF _Toc280690009 h 20Strengths PAGEREF _Toc280690010 h 21Weaknesses PAGEREF _Toc280690011 h 21Opportunities PAGEREF _Toc280690012 h 22Threats PAGEREF _Toc280690013 h 22SWOT Findings PAGEREF _Toc280690014 h 22Where do we go from here (Spring 2010)? PAGEREF _Toc280690015 h 23Section III PAGEREF _Toc280690016 h 24Define measurement data points for Test Case analysis PAGEREF _Toc280690017 h 24Section IV PAGEREF _Toc280690018 h 24Creation and Validation of the predictive model PAGEREF _Toc280690019 h 24Section V PAGEREF _Toc280690020 h 24Summary Analysis PAGEREF _Toc280690021 h 24Practical Usage PAGEREF _Toc280690022 h 24Praxis Conclusion PAGEREF _Toc280690023 h 24References PAGEREF _Toc280690024 h 25Books PAGEREF _Toc280690025 h 25Articles / Web Information PAGEREF _Toc280690026 h 25

Software Processing Methodology:

Understanding the Problem

Section I:

IntroductionIn this work, I examine three different Software Processing Methodologies. I start with the iterative model, followed by the spiral model, and conclude with the V-model. Each of these methodologies is discussed in length to gain a clear understanding of their similarities and differences. This paper focuses on gaining a key understanding of the methodologies and when it is best to utilize each. Each serves a special purpose; the process of understanding the problem one must solve remains as complicated as actually solving the problem itself. In this work, I will investigate the intricacies required to formulate the problem while also selecting the appropriate methodology. I will analyze each of the methodologies, their pros and cons, given problem we are intending to solve. The pure nature of the problem will not only dictate which methodology, but also foreground why. The why becomes critical to providing a solid response.

This work also provides an analysis of historical projects and examines their chosen methodology. I provide a complete breakdown of the thought process for entry into the methodology as well as an examination and summary of the life cycle model based on the chosen methodology. I conclude each with a summary of possible different outcomes if another methodology would have been selected to solve the same problem.

The end results of this work is intended to provide a new setup entrance criteria to select a software processing methodology based on the problem. Given the enormity of software processing methodologies, this work will sub focus on the requirement element of each model listed above.

Technical questionHow to determine which software processing methodology provides the optimal delivery of a complex solution with regards to functionality, cost, schedule, and quality, also known as the quad constraint (PMI, 2007).Quad constraint also known as triple constraint forms one of the most important concepts in the context of project management. Reis (2008) pointed out that the execution of a given project includes the alteration of three or four legs of a ‘stool’ that comprises of cost, time functionality and /or quality. A change in functionality would lead an increase in project cost and time. This means that an alteration of one leg of the stool would mean a change in the other legs of the stool. This praxis will examine three different software processing methodologies. The end goal is to develop a model that will predict which model should be used to deliver the given solution.

Deploying a solution that optimizes the quad constraint remains crucial to the survival of all companies. The quantitative portion of this praxis will focus on the requirements aspects of each model, but a full understanding of each model will be required. Requirements are the cornerstones of driving a successful project. Failure to produce and deliver quality and accurate requirements is the main cause of project failure with regards to the quad constraint. This praxis will not spend cycles reproving the value of software processes, but will rely on already proven works. This work will examine the various models to set the background and understanding of the value of each. The comparison is relevant to creating the final model for selection.

The extended technical question that drives the overall thought process hinges upon what solution works best in the current customer environment to deliver and support the end solution within the overall strategic business case. Companies struggle with understanding the multitude of approaches to deliver a complex technical solution. When choosing a methodology, organizations must consider the current resources available regarding people, processes, and technology within a given environment. The combination of building and maintaining a solution within the cost and revenue guidelines causes most IT leaders to move with caution on any technical decision, let alone the methodology. The focus is to help those leaders choose the best methodology so as to ensure success.

MotivationThe importance of the problem involves improving the number of successful deliveries in the context of the quad constraint. Projects always deliver. That is not the concern. Optimizing the delivery and reducing overall costs to improve revenue are the motivating factors behind selecting the best fit methodology. The goal is to help organizations select the right methodology and ramp up resources to drive the requirements phase of the project. Focusing delivery using the best fit methodology has proven to reduce costs and provide a better quality solution.

MethodologyThis work utilizes both academic and corporate theory to define a set of new entrance criteria for selecting the model to best solve the problem.

The following is the approach of this paper.

Introduction and Setup the Problem (Theory)

This information is provided in Section I and serves to set the stage for the problem we are attempting to solve. It also includes the rationale behind the work.

Analysis of three Software Methodologies (Theory)

This information is provided in Section II and will focus on defining the three methodologies along with the SWOT analysis for each. This section will conclude with recommendations on how to begin the definition of the data points required to build the predictive model for entrance criteria on methodology selection.

Define measurement data points for test case analysis (Theory plus Practical)

This information is provided in Section III and consists of evaluating six completed complex technical solutions using each of the models. The solutions selected are similar in nature and completed for a more comprehensive result. This section defines the data points for the predictive model.

Creation and Validation of the predictive model (Practical)

This information is provided in Section IV and is the mathematical representation in Excel that provides a methodology recommendation based on the input parameters and data points defined in section III. The model that will be used has not been finalized because it will rely on the data points defined in Section III. We will review and determine if the model will use semantic, UML, SysML or a combination. The final model will take inputs from the determined model (s).

Conclusion

This section provides a summary analysis of the findings as it relates to the research. This section will also discuss the practical usage of the model in a corporate versus academic environment.

Research and Contribution MethodsTextbooks, internet articles, current and past work experience, interviews with colleagues and discussions with other industry experts will guide and shape the outcome of this praxis. I plan to work with corporations, universities, and government agencies to acquire the required completed projects for the analysis against each methodology.

I will also take the predictive model into my current company and use it against new projects on the horizon. The goal of my praxis is to have three small projects created from start to finish using each of the three methodologies and conclude if the predictive model can be validated in a controlled sample.

Section II:

Software Processing MethodologiesDeveloping a system methodology means the structuring, controlling, and planning the development of a system of information (CMS,2005). There have been a number of such frameworks developed over the many years with each framework exhibiting its uniqueness in recognized strengths and weaknesses. In this consideration, all system processing methodology are not all good fits for all projects. Of course using the word “all” makes this statement true. The real focus is not which methodology does not fit, but rather which is the more optimal fit. In this section we explore the Waterfall, Iterative, and V-model methodologies. End results of this section are to provide the path to the data points required in section III.

Waterfall Methodology

The waterfall methodology is rather a sequential software development model for the entire solution (SBS,2011). It requires significant upfront activity and clear requirements. Most software development shops belittle the waterfall methodology as cumbersome and a slow providing a sequence of steps that are orderly and as well as developmental steps that ensure that design, reviews and documentation are of quality, reliability, and maintainability of the resultant software (Chapman, 1997). Key factors for the waterfall methodology are Products and Processes (MIT,2002).

All projects are better managed if they are broken down into a hierarchy of phases with some overlap allowed between the phases. Other chunks in which a project can be divided include stages, tasks activities and steps. Simplistic rendition in a system development project is usually called waterfall methodology with a focus on time schedules, planning, budgeting as well as implementation of the whole system at a time. Also, in this methodology, extensive documentation and use of extensively written documentation is used to maintain a tight control over the project in its entire lifespan. The waterfall methodology has seven (7) products; communicated requirements, requirements specification document, design specification document, executable software models, integrated software product, delivered software product, and changed requirements (QTP Blog, 2009). This also includes approvals or sign-offs at the beginning of a new project phase. A waterfall methodology is as shown in figure 1 below.

Fig1.The waterfall methodology

Hamlet and Maybee (2001, p15)

It is important to note that figure 1 depicts a few crucial principles of a good methodology which provides for; working in stages, conducting content reviews between the stages, reviewing decision points and establishing quality gates for the purposes of continuation. In terms of modeling, we look at the input and output parameters for each of the phases and assign a numerical value as it relates to the final data points.

Strengths

The waterfall methodology is suitable for applications with inexperienced project teams and management with less experience or in a situation where the composition of the project team fluctuates. In this scenario, it supports the continuity of the software development fully well. When strict controls are merged with orderly sequence and design reviews, the maintainability, quality and reliability of the developed software is assured. In addition to the conservation of resources, the waterfall methodology also ensures that every progress of the system development becomes measurable by the team or the managers. The waterfall methodology requires that the problem be well understood and requirements are well defined.

WeaknessesDue to the set tight controls and significant structures, the waterfall methodology is not only rigid, cumbersome and costly, but also a slow method of system development (). Also as the system development progresses, there are usually few steps backwards with this methodology. Since the users may not be able to clearly state what they actually need in the initial stages of the project, this methodology may not be suitable due to its dependence on early specification and identification of the requirements that should be included during the system development.

This methodology is often characterized by missing components, unexpected development needs as well as inconsistencies that are only discovered during system design and coding and in addition, most problems often go undetected until they reach a stage of system testing which may be a little late. While under this methodology, the performance of a system of software development cannot be tested until completion, underperformance may be difficult to correct and if changes are to be effected, they occur very late in a life cycle that are more costly. It has also been noted that this methodology involves numerous documentation steps which makes it difficult to update as process of development continues. Lastly, the waterfall methodology widens the gap between the developers and the users with a clear division of responsibilities.

OpportunityOne of the widespread uses of this methodology is its application in the development of a transaction-oriented batch or a mainframe-based system (CMS,2008). This methodology also finds application where a large, complicated and expensive program is to be developed and needs clear solutions and objectives. The methodology is only fit in situations where these is no pressure being mounted for immediate implementation of the developed software. In addition, this methodology also allows the project requirements to be put in a comprehensive and unambiguous manner in situations where the project requirements are stable and do not change throughout the time of development. Its applicability can also be valued when the community that uses it is fully knowledgeable in the application and business of the developed program. This is methodology fit for application in cases where the team members are inexperienced in the development or has not undergone a software development process. Consequently, when the system development team is expected to fluctuate or unstable due to the mobility of labor, this methodology may be appropriate in comparison to other methodologies.

ThreatsThis methodology is not fit for application in situations where there is a large project where the requirements are not understood or are changing for any reasons such as change in expectations, external changes, budget changes, or rapid a technological advancement since it is a less flexible process that does not allow dynamism (CMS,2008). The other weakness of the waterfall methodology is that it struggles when applied in implementing a Web Information System due to the usual pressure normally associated with any WIS project that need quick implementation, need for flexible and experienced team from various disciplines as well as the constant evolution of the requirements pertaining to the project. This methodology can also not be applicable in systems that are real time, even-oriented or driven or applications that require leading-edge technology. The challenge is also in partial implementing the rigor required for waterfall and thus falling out of process immediately. This methodology does not allow cleanly or quickly for such a situation.

Iterative MethodologyThe iterative methodology is a sequential software development model with iterations prior to the end solution. It is similar to writing a Praxis, draft, refined draft, final paper — each step of the way a product is produced and then refined.

Wiley (2010) describes the iterative software development approach/model is a combination of eXtreme Programming (XP) and Rational Unified Process (RUP). The objective is to achieve the “right level” of process aligned required delivery to meet business needs. The right level of process formality in this approach is achieved through the understanding of the challenges that are faced by the business environments of operation and the kind of development team. Once these challenges are have been taken care of, the exact process that is needed is applied in order to mitigate the risks involved. However, it is worth noting that there is never a one-size fits-it-all process irrespective of the weight of the process.

Source: CMS (2008).

The main values emphasized by this approach are:

Communication,

Simplicity,

Feedback

Iteration.

This model is used more often to handle certain portions and a rather larger and a more traditional methodology like incremental, Rapid Application Development (RAD) and spiral methodology. The methodology also attempts to reduce the inherent risks in the project through the breaking down of the project into minute segments and the provision of a more ease-of –change environment in the process of developing the software. The user of the software is also actively involved in the process throughout which aids in increasing their acceptance of the final project (CMS, 2008). There is also a design of small-scale mock-ups of the software system being developed via the iterative modification process up to the time the prototype is fully evolved in order to meet the requirements of the user. It is worth noting that even though most of the available prototypes that are developed with the ultimate expectation of being discarded; there exists a strong possibility in certain cases for an evolution to occur from a given prototype to a working system.

StrengthsThe first strength is that it addresses the problem of inability of various users to specify their informational needs as well as the difficulty of the various system analysts to effectively comprehend the user’s environment and thereby providing the many users with a rather tentative system used for the experimental purposes at a time considered to be the earliest possible (Janson and Smith, 1985).

The second strength is that it can be used in order to realistically model very important aspects of a given system at each phase of traditional software development lifecycle as pointed out by Huffaker (1986)

The third strength of this methodology is that it can improve the participation of the users in the process of system development as well as enhancement of communication among the various project stakeholders.

The fourth strength is that is very useful in the resolution of unclear objectives and the development as well as the validation of various user requirements; thereby results in the experimenting with as well as comparing certain design solutions.

The fifth strength is that a great potential exists for the process of exploiting the knowledge that is gained at a process of early iteration as the subsequent iterations are developed.

The sixth strength is that the methodology aids in the easy identification of rather confusing and difficult functions as well as the identification of the missing functionality.

The seventh strength is that this methodology of software development may in a way generate certain specifications to be used in the production of a particular application.

The eighth strength is that this methodology encourages the achievement of innovative and flexible designs.

The ninth strength is that this methodology provides a rather quick implementation of an otherwise incomplete but developmentally functional application.

The tenth strength is the output of each iteration allows management and the customer to get an idea and change direction almost real time.

WeaknessesThe first weakness of this methodology is that the process of approval and control is never strict. Too many people can have input throughout the process.

The second weakness is that inadequate and incomplete problem analysis is inherent in methodology. This is more common where the most obvious as well as the superficial needs are the ones to be addressed. The result is the transfer of the existing inefficient practices into the newly built system.

The third weakness is that the software development requirements may frequently change in a significant proportion.

The fourth weakness is that the process of identifying non-functional elements is usually very difficult to document.

The fifth weakness is that the designers of systems may prototype the application too quickly thereby ending up with an inferior product as a result of having sufficient expected user needs analysis.

The sixth weakness is that the designers may in a way neglect the various documentations that are necessary for the process of development and thereby resulting in a justification that is insufficient for the process of justifying the final product as well as the keeping of insufficient records for use in the future.

The seventh weakness is that it can easily lead to a poorly designed system whereby unskilled designers could substitute the process of prototyping for a more sound design. The result could be a quickly developed system that lacks global configurations to be used in the integration of other elements.

The eighth weakness is that it can lead to an entirely false expectation in which the customer is made to mistakenly believe that the software system developed is “completed” when the fact is that the process is not completed. The system may look as well as possess adequate user interfaces but it is never truly functional.

The ninth weakness is that the iterations usually add to the project budgets as well as schedules. These must be weighed against the potential benefits. Relatively small projects may never be able to justify the increase time and money. On the other hand, only the high risk projects may be gainful from the process of prototyping.

The tenth weakness is that the prototype may not be fitted with sufficient checks and balances in its design.

OpportunitiesThere are various opportunities that exists for the use of this model

The first one is that it can be used for the development of online systems that require extensive user dialog and also for the development of a relatively well-defined software system used as an expert and decision making support system.

The second opportunity is that it can be used for the building of large projects having a wide user base, functions and interrelations. The kind of projects where there is a need to reduce the project risk that relates to the requirements of definition to be reduced.

The third opportunity is that it can be used for projects that have unclear objectives.

The fourth opportunity is that it can be used for projects where pressure exists for the need of immediate implementation of a projects.

The fifth opportunity is that it can be used where the functional requirements are prone to change frequently and in a significant amount.

The sixth opportunity is that it can be used where the user is not in a state of complete knowledge of the system to be developed.

The seventh opportunity is that the team members gain a lot of experience in the cases where the prototype is never a throw-away.

The eighth opportunity is that the methodology can be used in situations that requires a stable team composition

The ninth team opportunity is that the methodology can be used effectively in situations where the team managers have a high level of experience.

The tenth opportunity is that the methodology can be used in a situation that needs no minimum amount of resources.

The eleventh opportunity is that the methodology can be used in situations where no very strict requirements are in existence for the process of approving a certain milestone that is designated.

The twelfth opportunity is that this methodology can be used where analysts and users do appreciate the integral business problems that are involved in the design prior to the beginning of project actualization.

The thirteenth opportunity is that this methodology can be effectively be used in situations that demand innovative and yet flexible designs in which the accommodation of future changes is never critical.

ThreatsThe overall threat for this methodology deal with transaction-oriented batch systems or mainframe-based systems; web or e-business systems; weak project teams; when scalability issues are not considered; and other such items (CMS,2008). The biggest threat to the iterative model is when objectives and requirements are lucid. The model does not have a clear flow or process to handle such situations. The number of iterations, defects, and overall delivery will all play significantly into the data points needed for the model.

V-Model MethodologyV-shaped model, like any other methodology, sets up methods, procedures, tools and techniques that are employed to steer the process of software development into completion until it runs (Husin,2009). V-shaped model is one such models that may be used to control the system development process. In choosing an ideal and effective is important in making sure that it is carried out in time to meet the client or user’s specification or requirement. This model sets out phases that are important in guiding those who develop systems. The life-cycle model in the figure below is helpful in to developers in planning, managing, evaluation and control of the information on the project. The V-shaped model consists mainly of six phases as depicted in the figure below. These are; system requirement followed system analysis, object design, implementation, testing and lastly, system documentation.

Figure 3: V-shape lifecycle model

Source: Husin (2009)

StrengthsThe strong points that would convince a team of system developers to adapt this software model are that the software requirements are already stated and clearly defined; the tools and technology that are used for software development are well in the knowledge of the team of developers. This life-cycle model is also a choice of many developers because it is easy and simple to use, and each of its phases have specific deliverables. This makes team managers to be able to quantify the amount of work that they have accomplished. There is also a likelihood of success since the test plans are developed earlier on in the life-cycle of the software development.

WeaknessesDespite the strengths discussed above, the V-shaped model struggles with solutions that are required to handle concurrent events. Further, it is unadvisable to use this model to handle iterations or phases in the software development process and just like the waterfall methodology, this mode does not handle dynamic changes in the client or the user requirements as it is a bit rigid and finally, this methodology does not have provisions that can be used for risk analysis in the event that these activities are required.

OpportunitiesWhen developers are interested in achieving systems that are highly reliable and excellent to the clients like patient control applications or reliable accounting software, the V-model comes in handy to such a team of system developers. In addition, all the requirements for such a system are known upfront and may not need alterations in the process of the development in a case where modification is necessary to handle the change in requirements, modification is still possible beyond the analysis phase and lastly, such a system in which the technology and solutions are known require very much the use of the v-model.

ThreatsJust like the waterfall model, v-methodology does not allow changes to the system until the complete coding is done. Rapid development and prototyping are also hindered with this methodology.

SWOT FindingsNow that we have a better understanding of the methodologies that will be used to generate the model, we have to ask for the common theme that determines the direction of each methodology. The common theme or golden string focuses on requirements. The level of requirements directly identifies the impact of the methodology as it relates to the quad constraint. A elements discussed in each of the SWOT analysis above will be used as input into the overall model to ensure that consistency and bias are removed if we only use one of the strengths of one methodology versus a combination. It is still is necessary to identify where the real problem exists in the domain of software development (CTG,1998). The functionality, cost, schedule, and quality quad constraints are a true portrayal of the exact problems that exists in software development. It cannot clearly be stated which model cost more, which will provide higher quality, which will impact functionality the greatest nor which is best for the schedule. The project needs and project constraints will predict which model should be used and will work best.

Where do we go from here (Spring 2011)?Analysis the SWOT findings and each SWOT analysis and create a set of data points 3-5 that align with creating the appropriate model. What values need to be captured and how to provide a clear prediction of the “best” model to use.

Develop a model that will predict which of three different methodologies should be used to deliver the given solution based on functionality, cost, schedule, and quality as it relates to the initial and final requirements.

Determine how to incorporate quality and functionality as part of the model. Cost and schedule data will be good measures for the end results.

This will help drive sections III, IV, and V.

Section IIIThe measurement points for this paper are based on the quad constraints of functionality, cost, schedule, and quality that are involved in the implementation of the three main Software Processing Methodologies; Iterative model, spiral model as well as V-model.

Functionality

Functionality is defined by PCMag (2011) as the actions, operation, usefulness as well as capabilities of something like a software application. In this context however, functionality would refer to the usefulness and the ability of a given software development life cycle (SDLC) methodology. This is to say that the project involves a thorough evaluation of the functionality of the three Software Processing Methodologies. We evaluate the functionality of the iterative model, followed by the spiral model, and conclude with the V-model.

Cost

Cost of implementing a given software methodology can be mea