Software Processing Methodology paper

Contents

Section I: 5

Introduction. 5

Technical question. 6

Motivation. 7

Methodology. 7

Research and Contribution Methods. 8

Section II: 10

Software Processing Methodologies. 10

Waterfall Methodology. 10

Strengths. 11

Weaknesses. 12

Opportunity. 13

Threats. 13

Iterative Methodology. 14

Strengths. 16

Weaknesses. 17

Opportunities. 18

Threats. 20

V-Model Methodology. 20

Strengths. 21

Weaknesses. 21

Opportunities. 22

Threats. 22

SWOT Findings. 22

Where do we go from here (Spring 2010)?. 23

Section III. 24

Define measurement data points for Test Case analysis. 24

Section IV.. 24

Creation and Validation of the predictive model 24

Section V.. 24

Summary Analysis. 24

Practical Usage. 24

Praxis Conclusion. 24

References. 25

Books. 25

Articles / Web Information. 25

 

 

Software Processing Methodology:

Understanding the Problem

 

Section I:

Introduction

            In 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 required element of each model listed above.

Technical question

How 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).The 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[1]. 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.  Thequantitative 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.

Motivation

The 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.

Methodology

This 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.

  1. Introduction and Setup the Problem (Theory)
    1. 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.
  2. 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.

  1. 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.

  1. 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).

  1. 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 Methods

Textbooks, 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 Methodologies

Developing a system methodology means 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 the implementation of the whole system at a time. Also, in this methodology, extensive documentation and use of extensively written documentation is used to maintain 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 1below.

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 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 problembe well understood and requirements are well defined.

Weaknesses

Due 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 the process of development continues. Lastly, the waterfall methodology widens the gap between the developers and the users with a clear division of responsibilities.

Opportunity

One 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 the 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.

Threats

This 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 Methodology

The 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:

  1. Communication,
  2. Simplicity,
  3. Feedback

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 evolution to occur from a given prototype to a working system.

Strengths

The 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 strengthis 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.

Weaknesses

The 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 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.

Opportunities

There are various opportunities that exist 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.

Threats

The 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 Methodology

V-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 into 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)

 

Strengths

The 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 software development.

Weaknesses

Despite 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.

Opportunities

When 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.

Threats

Just 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 Findings

Now 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 focus 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 exist 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)?

  1. 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.
  2. 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.
  3. Determine how to incorporate quality and functionality as part of the model.  Cost and schedule data will be good measures for the end results.
  4. This will help drive sections III, IV, and V.

 

 

Section III

The 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 measured in terms time or money (Bijay and Peter,2006). The high cost of developing software also carries other variables other that time and money. There are career as well as political costs of the software development methodologies. This is the reason as to why software development is referred to as an “electropolitical” problem as well as a high risk-project best described as a “death march” (Bijay and Peter,2006).

Schedule

Schedule in project management consists of a list of the terminal elements to be achieved as well as their intended start and finish dates. These terminal elements mark the lowest elements that exist in a given schedule. The items are usually estimated in accordance with the resource requirements, duration as well as budget and are linked by schedules as well as dependencies. Before a given  software development project schedule is created, the designated project manager must come up with a work breakdown structure (WBS)  in an bid  to estimate the amount of effort required for each task.An appropriate resource list is also used depicting the availability of each and every resource. For a given schedule to be deemed healthy, Project Management Institute (2003) pointed out that the following criteria have to be met;

  • The given schedule must be updated constantly
  • The value of the EAC (Estimate at Completion) must be equal to the value of the baseline
  • The residual effort must be distributed appropriately among the various team members.

Quality

Quality of a given project (software methodology)  may also be referred to as its scope. It denotes what has been agreed to be achieved by the given software methodology. In this case it will denote the functions ,data, features as well as content involved within a given methodology.

These measurement are however to be applied upon the created predictive model which is reliant on the outcome of the SWOT analysis of the Software Processing Methodologies; Iterative model, spiral model as well as V-model. This is carried out using a SWOT matrix. The developed SWOT matrixes are indicated below.

SWOT Matrix (Swotmatrix.com,2011)

The SWOT analysis matrix

One of the most widely used tools in software development as well as strategic planning is SWOT (Strengths, Weaknesses, Opportunities, and Threats) analysis. Several software development companies and individuals employ SWOT analysis in their designs in one way or another.It is worth noting that the worth of a given SWOT analysis depends on the objective outlook of the software developers who conduct the SWOT analysis. If the software developer or development team is to come up with an objective and yet relevant information to be used for the analysis then the outcome would surely be useful to the software development process.

The SWOT analysis entails the software development team’s assessment of all of the internal positions through the identification of the methodology’s strengths and weaknesses. The team must also determine the external positions through the definition of opportunities as well as strengths.

The strengths represent the main characteristics of the software processing methodology as well as key assets of the given methodology. Examples include the ability of the waterfall model to be used by inexperienced teams. The weaknesses on the other hand represent the areas in which a given software processing methodology does not perform quite well in.

The opportunities on the other hand include those current as well as future circumstances which may provide favorable condition to the employment of a given software processing methodology. Threats on the other hand represent the current as well as the future circumstances in the market that may present unfavorable conditions to the employment of a given software development methodology.

Once the software development team has identified both the strengths and the   weaknesses of given   methodology then they may be able to determine the significance of each. A special design team should then be able to review all of the strengths as well as weaknesses in order to determine the significance level (either minor or major) of the individual strengths and weaknesses. After the software development team has identified the strengths as well as the weaknesses, they would be able to determine the significance of each and every factor.

Section IV

Creation and Validation of the predictive model

What is predictive modeling?

Predictive modeling refers to the process that is employed in predictive analytics in order to come up with a statistical model that depicts the future behavior (SDM,n.d).Predictive analytics on the other hand is concerned with the data mining in regards to trends and forecasting probabilities.A predictive model comprises of a variety of predictors which are factorial variables that are most likely to influence the future behavior or outcomes. In this context, it would predict the likelihood of a given methodology to satisfy the most immediate business requirement in regard to the choice of the software methodology to be used in the completion of a given business software project.  In predictive modeling, the needed data is collected the a statistical model is then formulated and the predictions made on the basis of the collected data. The model is then validated or subsequently revised as more data is made available. The predictive model may make use of a simple linear equation or an extremely complex and neural network based equation that is mapped out by means of complicated software.

The process of data mining (source:IBIT,2011)

The creation of the predictive model

The predictive model to be used in choosing the most appropriate methodology is based on a variety of factors. These factors will act as the variables and constants in the created model. In order to come up with the best predictive model, it is important that all of the crucial factors that are active in the application of a given methodology be identified. It is however obvious that not all of these factors can be factored in in the predictive model. An inclusion of all of the factors would result in a model that is skewed and too complicated to use in computation. Our model would therefore be a truncated one but bearing all of the most crucial parameters. The predictive model to be used in the selection of the most suitable software processing methodology is presented empirically as using the most important predictor variables. Cost and Schedule are the main factors that are to be used as the predictor variables for this given case. This is because they are quantifiable. The predictive model was developed using the dataset available in Table 1. In order to comeup with the most appropriate predictive model, cost and schedule variable that were collected for the three software processing methodologies were incorporated into predictive model.

The construction of the predictive model depended on the data that consisted of 2976 (69%) successful and 1,332 (31%) unsuccessful implementations of a given software processing methodology. The dependent variable IMPLEMENTATION STATUS was appropriately coded as successful=1 and unsuccessful=0. A special software; SAS Enterprise Miner was employed in order to build the predictive models. This special data mining software provided a dedicated Graphical-User-Interface (GUI) workspace in which nodes (also called tool-icons) could be easily selected from a variety of tools existing on a palette and then subsequently placed on the given workspace.  The nodes were then connected to a specific form process flow diagram that explicitly structured and documented the flow of all the analytical activities

Section V

 

Summary Analysis

The analysis is contained in a separate datasheet and it is clear that Waterfall and V-Model are the best methodologies to employ if schedule and time are the main constraints.

Practical Usage

The practical usages of the results of this study are in the areas of software development project management. This is crucial in order for the corporations to maximize their returns in accordance to the chosen methodology. A successful methodology is one that aligns itself to the stipulated conditions that are guided by the choices made by the organization on the basis of the quad constraints

Praxis Conclusion

The praxis conclusion is based upon the outcome of the developed predictive model and it is clear that the best software processing methodology depends solely on the requirements of time and schedule that are laid down by agiven organization.

 

 

References

Books

Alexander, Ian, and Beus-Dukic, Ljerka (2009). Discovering Requirements – How to Specify        Products and Services

Bass, Len, and Clements, Paul, and Kazman, Rick (2003) – Software Architecture in Practice        (2nd Edition)

Chapman,JR ( 1997). Software Development Methodology a.k.a.  System Development Life

Cycle

Cockburn, Alistair (2001). Writing Effective Use Cases – The Crystal Collection for Software       Professionals
Easterbrooks, S (2001). Software Life cycles. Lecture notes from the University of Toronto,

Department of Computer Science

Janson& Smith (1985) “Prototyping for Systems Development: A Critical Appraisal,” MIS

Quarterly December 1985

Huffaker, D. “Prototyping Business Applications Within the Traditional

Life Cycle,” Journal of Information Systems Management, Vol. 3, No. 4,

Fall 1986, 71-74.

Lamsweerde, Alex van and Wiley John (2009). Requirements Engineering: From System Goals    to UML Models to Software Specifications

Lewis, Jeremy (2008). SDLC 100 Success Secrets – Software Development Life Cycle (SDLS     100 Most asked Questions, SDLC Methodologies, Tools, Process, and Business Models

Project Management Institute (2008). A Guide to the Project Management Body of Knowledge   (Pmbok Guide)

Robertson, Suzanne, and Robertson, James C (2006). Mastering the Requirements Process (2nd    Edition)

Tian, Jeff (2005) Software Quality Engineering – Testing, Quality Assurance, and Quantifiable     Improvement

Wiegers, Karl E. (2003). Software Requirements

Wiegers, Karl E. (2006). More About Software Requirements: Thorny Issue…

Articles / Web Information

MIT (2002).Waterfall model.

http://sunnyday.mit.edu/16.355/classnotes-process.pdf

 

Centers for Medicare and Medicaid Services (March 2008). Selecting a development approach

https://www.cms.gov/SystemLifecycleFramework/Downloads/SelectingDevelopmentApproach.pdf

 

Center for Technology in Government (1998). A Survey of System Development Process

Models

http://www.ctg.albany.edu/publications/reports/survey_of_sysdev/survey_of_sysdev.pdf

http://www.cs.toronto.edu/~sme/CSC444F/slides/L04-Lifecycles.pdf

 

Husin, N (2009). System methodology.

http://dspace.fsktm.um.edu.my/xmlui/bitstream/handle/1812/449/CHAPTER%203%20%20%20SYSTEM%20METHODOLOGY.pdf?sequence=4

 

Wiley, A (2010).Iterative Software Development Approach. In NCI Wiki

https://wiki.nci.nih.gov/display/CommonProjects/Iterative+Software+Development+App  roach

 

[1] See Reis (2008)


Get Professional Assignment Help Cheaply

fast coursework help

Are you busy and do not have time to handle your assignment? Are you scared that your paper will not make the grade? Do you have responsibilities that may hinder you from turning in your assignment on time? Are you tired and can barely handle your assignment? Are your grades inconsistent?

Whichever your reason may is, it is valid! You can get professional academic help from our service at affordable rates. We have a team of professional academic writers who can handle all your assignments.

Our essay writers are graduates with diplomas, bachelor's, masters, Ph.D., and doctorate degrees in various subjects. The minimum requirement to be an essay writer with our essay writing service is to have a college diploma. When assigning your order, we match the paper subject with the area of specialization of the writer.

Why Choose Our Academic Writing Service?

  • Plagiarism free papers
  • Timely delivery
  • Any deadline
  • Skilled, Experienced Native English Writers
  • Subject-relevant academic writer
  • Adherence to paper instructions
  • Ability to tackle bulk assignments
  • Reasonable prices
  • 24/7 Customer Support
  • Get superb grades consistently

How It Works

1.      Place an order

You fill all the paper instructions in the order form. Make sure you include all the helpful materials so that our academic writers can deliver the perfect paper. It will also help to eliminate unnecessary revisions.

2.      Pay for the order

Proceed to pay for the paper so that it can be assigned to one of our expert academic writers. The paper subject is matched with the writer’s area of specialization.

3.      Track the progress

You communicate with the writer and know about the progress of the paper. The client can ask the writer for drafts of the paper. The client can upload extra material and include additional instructions from the lecturer. Receive a paper.

4.      Download the paper

The paper is sent to your email and uploaded to your personal account. You also get a plagiarism report attached to your paper.

 

smile and order essaysmile and order essayPLACE THIS ORDER OR A SIMILAR ORDER WITH MAJESTIC GRADES TODAY AND GET AN AMAZING DISCOUNT

order custom essay paper