Verified Document

Software Processing Methodology Understanding The Problem Klyne Dissertation

Software Processing Methodology Understanding the Problem

Klyne Smith, DSE Candidate

Dr. Frank Coyle

Technical

Motivation

Research and Contribution Methods

Software Processing Methodologies

Waterfall Methodology

Strengths

Weaknesses

Opportunity

Threats

Iterative Methodology

Strengths

Weaknesses

Opportunities

Threats

Model Methodology

Strengths

Weaknesses

Opportunities

Threats

Where do we go from here (Spring 2010)?

Define measurement data points for Test Case analysis

Section IV

Creation and Validation of the predictive model

Section V

Summary Analysis

Practical Usage

Praxis Conclusion

Books

Articles / Web Information

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 are 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 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). Quad constraint an extension of the well-known triple constraint;, which consists of cost, functionality, and time. The triple constraint forms one of the most important concepts in the context of project management. However, as 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, and functionality and now includes quality as the fourth leg or constraint. A change in functionality would lead an increase in project cost and time along with possible impacts to quality. This means that an alteration of one leg of the stool would mean a change in the other legs of the stool[footnoteRef: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. [1: See Reis (2008)]

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 people, processes, and technology within 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.

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)

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

3. 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 also defines the data points for the predictive model.

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

5. 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 vs. 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 the structuring, controlling, and planning the development of a system of information (CMS,2005). There have been a number of frameworks developed over the many years with each framework exhibiting its uniqueness in recognized strengths and weaknesses. In this consideration, all system processing methodologies 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. The end result of this section are to provide the path to the data points required in section III.

The background of software processing methodologies

According to Royce (1970), the explicit models in the context of software evolution can be traced to the earliest project that involved the development of very large software systems in 1950's as well as 1960's.In totality, the most obvious purpose for the development of these earlier software development methods/models was to present a conceptual scheme to be used for the rational management of the software development systems. These schemes served as the main basis used to plan, organize, staff, coordinate, budget as well as direct all of the software development activities.

Boehm (1976) pointed out that since the 1960's several descriptions of the traditional (classic ) software life cycle have been postulated.Royce (1970) formulated the software life cycle by means of the now popular "waterfall" technique/chart. This is displayed in the figure below;

The "waterfall" chart effectively summarizes in one display how the development of large software is extremely difficult since it entails the execution of complex engineering activities/tasks that may need rework as well as iteration before the project is completed. These kind of charts are usually employed…

Sources used in this document:
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)

Boehm, B.,(1976) Software Engineering, IEEE Trans. Computer, C-25,12,1226-1241
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
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
http://dspace.fsktm.um.edu.my/xmlui/bitstream/handle/1812/449/CHAPTER%203%20%20%20SYSTEM%20METHODOLOGY.pdf?sequence=4
http://predictivemodels.ibit.org/beauty/
http://www.swotmatrix.com/
https://wiki.nci.nih.gov/display/CommonProjects/Iterative+Software+Development+App roach
http://www.pcmag.com/encyclopedia_term/0,2542,t=functionality&i=43589,00.asp
Cite this Document:
Copy Bibliography Citation

Related Documents

Software Development Life Cycle
Words: 2835 Length: 10 Document Type: Essay

Software Development Life Cycle Agile Software Development Agile software development is a popular software development process or methodology that has gained a lot of popularity in the recent years due to its effectiveness and ease of use. Firstly, it encourages collaboration and teamwork throughout the life cycle of development and this makes it easy to plan and implement. Agile software development is all about breaking a task into small chunks that make it

Software Development Life Cycle SDLC
Words: 3695 Length: 12 Document Type: Essay

Software Development Life Cycle ( SDLC) Explain Requirement process ( in SDLC) in detail. Why is this exercise important? Requirements engineering is a fundamental activity in systems development and it is the process by which the requirements for software systems are identified, systematized and implemented and are followed through the complete lifecycle. Traditionally engineers focused on narrow functional requirements. Now it is being argued by Aurum and Wohlin (2005) that focusing only

Software Development Life Cycle
Words: 1559 Length: 5 Document Type: Essay

Software Development Life Cycle Social Media Software Implementation Project Social media is an important aspect of every business today because it gives companies a unique chance to understand the customers better and to interact with them at a more personal level. A wide range of social networking tools are used by companies to attract customers to the products and services offered by the company and this makes social media software implementation essential

Software Documentation Is an Integral Part of
Words: 828 Length: 3 Document Type: Essay

Software documentation is an integral part of the software development process. However, the process is often challenging because over the course of a software development project the scope can often change and evolve several times with updates and new builds. Despite the challenges that are presented in effectively documenting the development process, the documentation that is produced can serve as a valuable asset that can be used in future projects

Software Requirements Analysis: Implications for
Words: 780 Length: 3 Document Type: Article Critique

On this aspect of agent-based SDLC performance, both approaches are limited in terms of their applicability and scalability. The reliance on heuristics can only go so far with the embedding of business, technical and organizational elements into the overall structure of an SDLC methodology (Kumar, Goyal, 2011). The reliance on an agent-based model fits well with the development of modules that are designed to align with these innately unquantifiable

Software Application Process
Words: 1329 Length: 4 Document Type: Research Paper

Software Application Process for a Clinician Provider Order Entry (CPOE) system Software Application Process Clinician Provider Order Entry (CPOE) System The planning, customization, launch and continued use of a Clinician Provider Order Entry (CPOE) system in a local hospital forms the foundation of this analysis. The processes being used prior to the systems' planning and implementation are detailed to provide a basis of comparison of system contribution and performance. A timeline of the

Sign Up for Unlimited Study Help

Our semester plans gives you unlimited, unrestricted access to our entire library of resources —writing tools, guides, example essays, tutorials, class notes, and more.

Get Started Now