John Therrell

Edge Detection Program

jtherrell — Wed, 13 Jul 2011 20:33:37 +0000

A C++ edge detection program I implemented during the course of my Computer Vision coursework.

FTP Client Program

jtherrell — Wed, 13 Jul 2011 19:45:53 +0000

A fully-featured ftp client program I developed in C++ as a final programming assignment for my Networking class.

An overview of web services

jtherrell — Thu, 17 Feb 2011 19:54:46 +0000

A web service is a software system designed to support interoperable machine-to-machine interaction over a network. Web services are casually described as “Web APIs” by web service providers such as Flickr, Google, Twitter, etc. Web services can communicate over any choice of network protocol, however, Hypertext Transfer Protocol (HTTP) over TCP/IP is the de facto standard protocols of choice.

Anatomy of a web service

Web services live on the web, thus requiring at the minimum web server functionality that is capable of sending and receiving HTTP messages. A typical web service accepts an HTTP request from some I/O channel, processes it internally, and outputs an HTTP response, which is sent back to the client. This is done in a loop, until the application is commanded to exit. This does not necessarily mean that the web application speaks HTTP directly: it just means that the web application accepts some kind of representation of an HTTP request.

Web services are implemented following one of four architectures:

The web application is contained in an application server. This application server may or may not be able to contain multiple web applications. The application server is then connected to the web server. The web server dispatches requests to the application server, which in turn dispatches requests to the correct web application, in a format that the web application understands. Conversely, HTTP responses outputted by the web application are sent to the application server, which in turn sends them to the web server, and eventually to the HTTP client.

The web service is contained in a web server. In this case, the web server acts like an application server. This is the case for PHP applications, on Apache servers with mod_php. Note that this does not necessarily mean that the web service is run inside the same process as the web server: it just means that the web server manages applications.

The web application is a web server, and can accept HTTP requests directly. This is the case for the Trac bug tracking system, running in its standalone server. In many setups, such web applications sit behind a different web server, instead of accepting HTTP requests directly. The front-end web server acts like a reverse HTTP proxy.

The web application does not speak HTTP directly, but is connected directly to the web server through some communication adapter. CGI, FastCGI and SCGI are good examples of this.

Types of web services

There are two types of web services, big web services and RESTful web services.

These web service types can be differentiated upon inspection of how they answer the following questions:

How does the client convey its intentions (method information) to the server?

Big web services convey method information by passing a XML document which contains elements that indicate the method to be invoked. RESTful web services have the client convey method information using a restricted set of standardized HTTP methods (GET, PUT, POST, DELETE, HEAD, etc).

How does the client convey which part of the data set (scoping information) to operate on?

Big web services convey scoping information the same way they convey method information, passing scoping information in the same XML document. RESTful web services convey scoping information within the Uniform Resource Identifier (URI).

Big web services

Big web services today are generally web services which employ a number of web service specifications, including SOAP, WSLD, UDDI, and the WS-* suite of specifications. Big web services generally have one URI representing the entire service. All method and scoping information is passed with a SOAP message.

SOAP

SOAP stands for simple object access protocol as is a protocol specification for exchanging structured information in web services. SOAP messages are essentially an XML document that is added to the entity-body of an HTTP envelope. SOAP also utilizes XML schemas to govern and restrict the structure of the SOAP XML document, including the document structure and XM-defined standardized data types. SOAP messages are structured as:

WSDL

WSDL is an XML based language (adhering to standard and application specific namespaces and schemas) used for describing the interface of a web service. WSDL allows client applications to use code generation tools to generate stub classes based on interpreting the WSDL document. WSDL documents may also include non-functional descriptors to share metadata about the web service. Examples of such non-functional data are QoS, availability, and security considerations.

UDDI

UDDI is a XML based framework for machine-to-machine registry and discovery of web services through the use of a centralized registry. – UDDI registry entries consist of white pages (info about the services owner and contact info), yellow pages (industrial categorizations based on standardized global taxonomies), and green pages (the attached WSDL document). Public UDDI registries on the internet now seem nonexistent after Microsoft, IBM, and SAP chose to close their public UDDI nodes on January, 2006.

**WS-* specifications**

the WS-* suite of specifications provide added-features to SOAP-based messaging to support reliable messaging, security, addressing, and other features. Additional information about the suite of WS-* specifications can be found at http://www.infoq.com/articles/ws-standards-wcf-bustamante.

RESTful web services

REST stands for representational state transfer, a term coined by Roy Fielding, one of the principle authors of the HTTP specification for versions 1.0 and 1.1. Representational state transfer refers to the transferring of representations of resources on the internet, each expressed with a URI, through a standard uniform interface. RESTful web services conform to REST by using the standard uniform interface provided by HTTP’s set of methods to convey its method information to the server.

Todays web is mostly scattered with RESTful/RPC hybrid web services. These services are mostly RESTful, yet choose to put method information inside the URI and call the same HTTP GET method for any type of method invocation (ex. calling HTTP GET for reading data or deleting that same data).

When writing RESTful web service clients, it is important to find a HTTP library that supports at least the five main HTTP methods, allows for customizing data sent as the entity-body of a PUT or POST request, allows for customizing a HTTP requestʼs headers, and is able to communicate through a HTTP proxy, and supports HTTPS and SSL certificate validation. You will also need an XML or JSON parser depending on what the service uses as a data-interchange format.

Resource-Oriented Architecture (ROA)

The Resource-Oriented Architecture is a RESTful architecture that focuses on providing addressability, statelessness, connectedness, and a uniform interface in a web service implementation and is built on the notion that everything on the web with a URI is a resource:

Addressability - The ability to reference any resource that a web service provides. A resource is anything thats important enough to be referenced as a thing in itself. It is something that can be stored on a computer and represented as a stream of bits. This could be a document, the result of running an algorithm, or the representation of a physical object like an apple.

Statelessness – Every HTTP request happens in complete isolation – All HTTP requests include all information necessary for the server to fulfill the request. Possible states of the service are also resources, and should be addressable and given their own URIs.

Connectedness – Resources should have URI links to close or related resources in an appropriate context for that resource, much in the same way the HTML web works. This allows easy navigation between states, as states are

considered resources and have their own URIs.

Uniform Interface – Use of existing HTTP methods to convey method information on a given resource (GET, PUT, POST, DELETE, etc).

Common data-interchange formats used by web services

Interaction with any web service requires the exchange of data. An application could be receiving a list of names or adding a new name to the same name list that resides on the web service. In one first case, data is being sent from the web service server to the client application. In the second case, data is being sent from the client application to the web service. Today’s web services use structured, open-specification data-interchange formats for providing a uniform interface when providing and parsing through formatted data. The most popular data-interchange formats in use today are EXtensive Markup Language (XML) and JavaScript Object Notation (JSON).

XML

XML is a self-descriptive markup language which shares syntax similar to HTML through the use of tags. The author of a XML document can invent their own tags, using keywords in tags to describe the data they encapsulate. The following is an example of an XML representation of a note from Jani to Tove providing a reminder not to forget him this weekend:

Tove

Jani

Reminder

Don’t forget me this weekend!

JSON

JSON is a lightweight, self-describing data-interchange format which is quickly gaining popularity due to its simple serialization into a data structure representation. JSON is built on two structures: a collection of key:value pairs (dictionary, hash table) and an ordered list of values (array, vector, list, sequence). The { } bracket pair is a representation of an object, with its representation described as a set of key:value pairs. The [ ] brackets signify an array of objects, each object separated by a comma delimiter. The following is the JSON representation of the note which we created an XML representation of in the previous section:

{

note:{

to:’Tove’,

from:’Jani’,

heading:’Reminder’,

body:’Don’t forget me this weekend!’

}

Web service frameworks

A number of web service frameworks have been created over the past ten years to simplify the development of web services and web applications. Here are some details for three particular web service frameworks which are popular in today’s web service development:

Ruby on Rails

Ruby on Rails is an open-source, Ruby-based web application and web service framework intended to be used to develop web applications and web services rapidly. The Ruby on Rails framework is arguably one of the most popular framework used by developers of today’s modern web applications and web services, praised for its “convention over configuration” philosophy which allows rapid development of web applications and web services through code generation tools and sensible default configurations. Documentation and code examples are plentiful and of high quality.

Restlet

Restlet is an open-source, Java-based web application and web service framework which supports development of both web service client and server applications. Restlet provides no code generation tools and mild amounts of configuration must be done prior to successfully running a web service reachable at a given ip address and port. Documentation and code examples for the Restlet framework are minimal, resulting in greater difficulty for a developer to learn how to use the framework.

Play!

Play! is another Java-based web application and web service framework that seems to have more documentation and code examples compared to the Restlet community. Play! is heavily inspired by the Ruby on Rails framework, with the “convention over configuration” philosophy implemented to simplify the development of web services.

Web service resources

programmableweb.com – A human-readable, searchable and categorized registry of web services which are available on the web today for consumption.

Amazon web services – A free web service hosting service.

Google App Engine – Another free web service hosting service.

References

http://www.w3.org/TR/ws-arch/#whatis
http://www.modrails.com/documentation/Architectural%20overview.html#typical_web_applications
http://en.wikipedia.org/wiki/Universal_Description_Discovery_and_Integration#History
Richardson, Leonard; Ruby, Sam (2007). RESTful Web services. O’Reilly Media.

Letter from Greg Paskett, Sr Specialist, Program Mgmt ITS Hosting, Network & Information Security

jtherrell — Tue, 27 Apr 2010 12:17:00 +0000

To Whom it May Concern:

As a Senior IT Network Project Manager with Avanade for 3 years and Network Implementation Project Manager for AT&T Mobility for 6 years prior, I highly recommend John Therrell as a candidate for employment. John was an intern with Avanade starting in January, 2008 and I had the pleasure of working with John on two specific projects:

· Network Security Monitoring – The Network Security Monitoring system is a security toolset that will allow ITS department to identify and monitor network behavior, utilization, and configuration for security, capacity planning, and maintenance.
· BitLocker Deployment – Microsoft® BitLocker™ Drive Encryption protects data when a computer is in unauthorized hands or is running an exploiting operating system. BitLocker does this by preventing an unauthorized user who boots another operating system or runs a software hacking tool from breaking file and system protections, or even viewing the files that make up the operating system itself.

John’s role on both projects was Quality Assurance Specialist. He was held accountable for all aspect of Quality Assurance and Testing including planning, test case creation/execution and defect tracking/resolution for the projects. John successfully completed his deliverables, adjusting planning and execution according to customer needs while maintaining the high-level quality we demanded.

Some of the skills and knowledge I witnessed John used to complete these deliverables:

· Understood QA activities in relation Avanade project implementation methodology
· Developed QA Plan and all test cases
· Provided good estimates for task duration
· Identified QA process issues and either provided solution or escalated
· Managed defects and resolution path
· Actively participated on project team, clearly providing QA skills and knowledge

From my Project Manager perspective, John was very easy to work and I appreciated his proactive attitude with ways QA could improve delivery. His interpersonal skills make him an excellent team member. John demonstrated he could work independently, utilizing his organizational skills. Our customer changed focus and priority during the Network Security Monitoring project which resulted in significant changes to QA Plan. John was never deterred, instead reaching out to the customer to completely understand his needs resulting in high quality test cases. John also worked closely with other teams on a number of occasions and was able to juggle his priorities accordingly.

I would therefore highly recommend John Therrell. If his performance on these two projects is a good indication of how he would perform as a employee, he would be an extremely positive asset to your organization and company.

If I can be of any further assistance, or provide you with any further information, please do not hesitate to contact me.

Sincerely,

Greg Paskett | Sr Specialist, Program Mgmt
ITS Hosting, Network & Information Security
Avanade Inc | Seattle Service Center
818 Stewart St., Suite 400, Seattle, WA 98101

Letter from Brent Sommerseth, Avanade QA Infrastructure Team Lead/Supervisor

jtherrell — Tue, 02 Feb 2010 11:03:52 +0000

January 29,2010

Letter of Recommendation for John Therrell

I hired John Therrell as an SE intern on Avanade’s Infrastructure QA team in January of
2008. During his internship I was his direct supervisor up until my departure from
Avanade in June of2008.

In a largely Microsoft environment, John provided support for our physical and virtual
server environments ranging from hardware installations to software deployment and
troubleshooting. He was a valued team member who brought an attention for details to
his work. John worked well with our cross functional teams and had many opportunities
to assist these teams in an Infrastructure QA capacity. The feedback I received from
other team members was positive and I was happy to have John represent our team with
technical project efforts.

Some projects and/or tasks of note that John played a role in include: Vista bitlocker
deployment testing, writing and executing test cases for Infrastructure QA projects, and
assisting with the migration of Microsoft Virtual Server 2005 virtual machines to a
clustered Hyper-V environment.

John’s professional manner and willingness to collaborate added to his value as a team
member. It was a pleasure working with John and I am happy to provide this letter of
recommendation and to see his career continuing in the Information Technology field.

Regards,

Brent Sommerseth
Avanade QA Infrastructure Team Lead/Supervisor 2006-2008

Simple Drawing Application

jtherrell — Tue, 02 Feb 2010 07:40:11 +0000

A simple, Java-based drawing application I implemented during my Computer Programming II course. The main goals of the program were to gain experience designing graphical user interfaces (GUIs) and to practice use of the Model-View-Controller (MVC) architectural pattern.

John Conway’s Game of Life

jtherrell — Tue, 02 Feb 2010 07:36:28 +0000

A fun Computer Programming I assignment which exposed us to GUI design, two-dimensional arrays, and cellular automata. Implemented in Java.

Crossing the Chasm: Still An Effective Marketing Strategy For Today

jtherrell — Mon, 01 Feb 2010 09:00:26 +0000

In 1991, Geoffrey A. Moore published a marketing strategy for companies offering high tech products during the early startup period. Since it’s publication, Moore and his publisher’s hopes of selling 5,000 copies was trumped by over 300,000 copies sold (Moore). Eighteen years after its publication, Crossing the Chasm has established and maintained the status of a classic marketing strategy book for startups with high tech, discontinuous products. Crossing the Chasm contains a marketing strategy that is appropriate for today’s startup companies. It offers a marketing approach that addresses the hurdles that a startup must overcome to achieve mainstream adoption of their innovative products. Several companies have attempted to implement Moore’s Chasm Model with mixed results. Through an examination of the companies that failed and succeeded when using the Chasm Model, it is arguable that the Chasm Model is an effective marketing strategy for a startup company offering a high tech, discontinuous product.

An Examination of a Company That Followed the Model

Documentum Inc – Document Management System

Documentum Inc. was in a fantastic position when their enterprise-level Document Management System software was released. Its venture capitalist investors were advocating towards a marketing strategy that would target the entire mainstream market (Lal and Lanagan 7). At the time, all of Documentum’s competitors were marketing to the entire mainstream market (Lal and Lanagan 6). Documentum’s new CEO, Jeff Miller, had a difficult decision to make when he ultimately chose to follow Moore’s Chasm Model and focus on a vertical market segment opposed to a horizontal market strategy.

Documentum followed the Chasm Model’s target market selection process exactly as prescribed by Moore. Documentum not only adopted the Chasm Model as their Marketing Strategy, but also paid to have Geoffrey Moore’s Chasm Group provide consultation to the company and assist in identifying potential market segmentations for the company to target. After the analysis, the following five market segments were suggested: Insurance Policy Documentation, Aircraft Maintenance Documentation, Pharmaceutical NDA, Chemical Regulation Management, and Telecom Manufacturing (Lal and Lanagan 8).

From their market segment analysis, Documentum chose to target the Pharmaceutical NDA as their niche market. The business process they chose to target was the labor intensive task of preparing a new drug application for the Food and Drug Administration (“History of Documentum, Inc”). A new drug application consisted of hundreds of thousands of pages, which cost pharmaceuticals a considerable amount of money in labor required to compile and organize the application. Documentum saw an opportunity where their software could help shed off time and expenses associated with this business process.

With a clear vision of the beachhead to attack, Documentum made changes to their document management system software to add customization to support the FDA application process. After these changes were made, the company began to shop their product around to big pharmaceutical companies like Merck and GlaxoSmithKline. Merck and GlaxoSmithKline became adopters of the product and other pharmaceutical manufacturers soon followed.

From 1993 to 1994, Documentum increased revenues by from $2M to $10M, with revenues from pharmaceuticals accounting for 70% of their total revenue. From this strong position in their beachhead market, Documentum was able to continue its domination over other vertical market segments successfully (“History of Documentum, Inc”). The ultimate mark of success happened when EMC ended up acquiring Documentum for $1.7 billion in December 2003. Documentum followed the Chasm Model and was rewarded heavily for their decision to do so.

An Examination of Companies That Fell From the Model

Linden Labs – Second Life

In 1999, Linden Labs, creator of Second Life, was founded by Phillip Rosedale after his move from Real Networks to focus on the development on his vision for Second Life. He imagined a virtual world that would immerse its customers in massively multiplayer interactive environment. In 2003, Second Life launched and immediately was faced with skepticism that demand would be low for its virtual world without a story or game supporting the user experience (Eisenmann and Wagonfeld 1). When the company approached the chasm, it attempted to follow the Chasm Model, however, did not shown that it followed Moore’s marketing strategy as it is prescribed in his book.

Over the first five years of Second Life’s operation, Linden Labs has seen a total of 16.8 million unique avatars created. Of these 16.8 million, only 941,000 had logged into the virtual world in the last 30 days. 522,000 had logged into the world in the last seven days (Eisenmann and Wagonfeld 3). These findings troubled Linden Labs, who realized after investigation that only 10% of newly registered customers were logging in on a weekly basis after the first three months. Lack of growth was becoming as serious concern, with half the average user registrations happening in 2008 compared to 2007. This data indicates that Second Life had approached the chasm and needed a marketing strategy to gain entry into the mainstream market. Second Life’s usage hours were increasing strongly, but was projected to decrease due to a drop in growth rate.

From the case study analysis by Thomas Eisenmann and Alison Berkley Wagonfield, the authors described the details of Linden Labs application of the Chasm Marketing strategy. In their case study, Linden Labs demonstrated that, with the exception of selecting an appropriate niche market to target, they clearly covered all of the bases in following Moore’s marketing strategy. There was speculation about the appropriate market segmentation to target, however, it does not appear that Linden Labs decided to target their attack to any particular market segmentation. Customer segmentation analysis had never been completed by the company (Eisenmann and Wagonfeld 4), which is a strong indication that their marketing approach did not place a heavy emphasis on following Moore’s niche market targeting approach as prescribed.

Centra Software – eLearning and eMeeting

Centra Software is another example of a company who failed to prescribe to Moore’s Chasm Marketing strategy. In 1997, two years after the company’s creation, Centra’s flagship product, Symposium, was released. Centra was a pioneer in the eMeeting and eLearning marketplace, but quickly was challenged by competitors offering similar products such as WebEx and IBM. Despite the competition, Centra was the market leader for it’s delivery platform product, holding about 50% of the total revenues for the past three years over IBM, Mentergy, and Interwise (Deighton and Poullquen 3).

It was always the goal of Centra Software to become the leading eLearning and eMeeting product provider to Global 2000 corporations. In selecting the appropriate niche market to target for its marketing strategy, Centra Software chose to continue to focus on Global 2000 corporations, with a special emphasis on the top 200 companies within the Global 2000 (Deighton and Poullquen 1). This type of market segmentation failed Centra failed because, unlike Moore’s niche market characterics, Centra’s market segmentation did not make up a vertical industry or market. The Global 2000 is simply a list of the 2000 largest and most successful companies throughout the world. Global 2000 companies cover a wide variety of industries, from oil companies to financial institutions. This resulted in being able to focus in on a market segmentation, however, prevented Centra from creating a unique value proposition that would be strong for a particular vertical market. The result was that Centra’s market segmentation choice was not a traditional fit according to the Chasm Model.

The result of Centra’s choices was that they had to challenge a number of competitors head on with highly competitive companies with on-the-market products competing. Centra also was troubled by their distribution strategy weaknesses and their challenges when making adjustments. WebEx, one of their most serious competitors, was generating nearly all of its sales through telesales (Deighton and Poullquen 3). This approach was working very well for WebEx, and Centra found themselves troubled by their lack of a telesales force. Sales over the telephone would allow Centra to reach Global 2000 corporations quicker and cheaper than its existing field sales force could provide. Despite their best efforts to augment their distribution strategy, Centra’s case study findings showed their distribution strategy was not working smoothly to maximize sales.

According to Paul Gudonis, Centra Software’s President and CEO hired in July 2003, Centra was failing was due to it’s sales force fighting WebEx and Microsoft for the sale of Centra’s product as a general-purpose online meeting solution (“Centra Software: Lessons Learned?”). This explanation provided by Gudonis confirmed that the company had failed to focus their product to address a specific market segment. Centra’s salesforce was attempting to sell their product to a variety of companies with different business processes and different needs. This finding is a clear indicator that Centra Software did not follow the Chasm Model’s prescription to target a market segmentation.

Conclusion

The case studies of Documentum Inc., Linden Labs, and Centra Software all provided an interesting view into the actual implementation of Moore’s marketing strategy into their company’s Go To Market strategy. If Linden Labs and Centra Software’s mistake of selecting an inappropriate market segmentation could have been avoided, the Chasm Model would have probably led to greater adoption of their products by the early majority. Documentum Inc. provided a strong, real world example that the Chasm Model can be highly effective in gaining entry into the mainstream market. From the study of these company’s target market selections and their ultimate level of success, there is sufficient real-world evidence that the Chasm Model is an appropriate marketing strategy for today’s startups looking to offer high tech, discontinuous products.

Bibliography

“Centra Software: Lessons Learned?” Baseline Magazine. Ziff Davis Enterprise. 13 January 2005. Web. 11 December 2009.
“History of Documentum, Inc.” Reference for Business. Web. 6 December 2009. .
Deighton, John, and Laetitia Poullquen. “Centra Software.” Harvard Business School Cases (2002): 1. Business Source Complete. EBSCO. Web. 6 Nov. 2009.
Eisenmann, Thomas R., and Alison Berkley Wagonfeld. “Linden Lab: Crossing the Chasm.” Harvard Business School Cases (2009): 1. Business Source Complete. EBSCO. Web. 6 Nov. 2009.
Lal, Rajiv, and Sean Lanagan. “Documentum, Inc.” Harvard Business School Cases (2002): 1. Business Source Complete. EBSCO. Web. 6 Nov. 2009.
Moore, Geoffrey. “Geoffrey A. Moore on Crossing the Chasm.” April 2002. Web. 7 December 2009.

What is Software Engineering?

jtherrell — Fri, 29 Jan 2010 00:47:41 +0000

Over the last several decades, software has become increasingly complex. As software has grown to be such a complex monster, the practices of informal software development quickly failed to demonstrate their value. Projects that were developing software informally were often years late, over budget, unreliable, and difficult to maintain. It is only natural that a new engineering discipline was created to provide order to the process of developing software and to work toward providing a solution to the problems software development were facing.

Software Engineering: a Definition

Software engineering is an engineering discipline that is involved in all aspects of software production, from start to finish (Sommerville, 2004). From the beginning phase of gathering requirements for a software product to the final phase of maintaining software after it’s been released, software engineering is ever present. As an engineering disciple, theories, methodologies, tools, and techniques are defined and used to provide organization and efficiency toward software production. Ultimately, developing software using a software engineer’s approach is done in an effort to meet the goals that today’s technological environment demands.

The Goals of Software Engineering

Software engineering is deeply concerned with providing a means to help development teams meet the expectations of their customers. Today’s companies and customers expect the following (Pressman, 2010):

Software is to be of high quality.

Customers expect that software they use will be reliable and will perform as expected.

Software is produced cost-effectively.

Software development teams are expected to produce software that will meet the expectations of the customer while at the same time staying within their set budget. In the real world, this is easier said than done. Nonetheless, software engineering helps to provide a systematic approach that will allow for better estimation of project costs.

Software is easily maintainable.

Most of us have heard of the term “spaghetti code.” It is definitely possibly to write a program that functions and performs what is required and still be written poorly. Through proper planning and design, development teams can ensure that their software is developed in ways to ensure it’s easily maintainable.

Software is developed in a timely fashion.

The world of technology is changing every day at a rapid pace. Companies rely on utilizing new technologies to enhance productivity and gain a competitive advantage. If software cannot be developed and delivered in a timely fashion, development teams run the risk of their products becoming outdated or cooled down.

The Practice of Software Engineering

Underneath all of the processes, methodologies, and tools within software engineering lies an underlying set of practices that really are at the heart of what the philosophy is behind an engineered approach to software development (Pressman, 2010). Think of the software development process as a problem solving process. The problem is that you have a software product to develop that needs to fulfill a list of requirements specified by your customer. The solution is a completed software product that meets the customer’s requirements. Software engineers use the following four engineering practices to solve the problem: understand the problem, plan a solution, carry out the plan, and examine the result for accuracy. These practices are present in various activities through software engineering process activities.

The Software Process Framework

Through review of all the various software processes that have been developed over the relatively young discipline of software engineering, a generic software process framework has been observed time and time again (Pressman, 2010). Within this framework is a set of framework activities and umbrella activities:

Framework Activities

Communication

It is absolutely essential to communicate and collaborate effectively in any software process. Requirements gathering, a major communication activity, is required to understand what functionality the software requires.

Planning

Planning allows for teams to look at the software project’s present and future paths in an organized manner. Without planning, any development team is destined to be ridden with inefficiency, stress, and an excess of complications.

Modeling

Allows development teams to look at the big picture when designing and developing the software product. Modeling helps in understanding the complexities of today’s modern software.

Construction

Consists of the actual code generation and testing activities. These two activities are generally found in all software development projects, even informal ones.

Deployment

The delivery of software to the customer. Can be either a release version or a partially completed, increment of the software product.

Umbrella Activities

Software project tracking and control

Monitors the progress of the project compared to planned progression. Allows teams to know if they are falling behind schedule so they have opportunities to take action to get caught up.

Risk Management

Allows teams to assess the risks a project faces that may affect the quality or outcome of the project.

Software Quality Assurance

Involves designing a test plan to ensure software meets quality requirements.

Technical reviews

Reviews the work done thus far in a project. The goal of this activity is to ensure that work products are complete before moving on to the next set of work activities.

Measurement

Also known as metrics. Provides information to assist in delivering software that meets the customers needs.

Software Configuration Management

Manages and monitors the effects of changes to through the software process

Reusability Management

Explores the potential for reuse of assets, such as existing code, to help reduce the costs and time of a software project.

Work Product Preparation and Production

Contains a collection of activities used in the development of work products such as models and documentation.

Software Engineering is a Layered Technology

As with all other engineering disciplines, software engineering is committed to delivering quality to the production of a product. A focus on quality is what drives software engineers to improving software engineering processes. This is the reason that a quality focus is the bedrock of software engineering (Pressman 2010).

In an effort to provide quality to a product’s development, processes are the foundation of software engineering. Processes exist as a collection of activities, actions, and tasks that are carried out during the development of a software product. Essentially all of the high-level management and strategies live in this realm.

Software engineering processes make use of methods to carry out the activities of the software development process. Think of methods as the technical know-how to actually carry out the work required to develop software. Communication, testing, requirements gathering, and design modeling are just a few examples of methods that processes use.

Methods in software engineering make use of tools to help with the execution of methods. Many of the tools used by software engineers are, in fact, software based! Communication makes heavy use of email and instant-messaging application. Programmers make use of text editors or integrated development environments. These tools help to provide automation and/or assist the methods with completion of work.

List of Works Cited

Sommerville, Ian. Software Engineering, 7th ed. Pearson Education Limited, Edinburgh Gate 2004.

Pressman, Roger S. Software Engineering: A Practitioner’s Approach, 7th ed. McGraw Hill, New York 2010.

Bayfront Builders Website

jtherrell — Tue, 19 Jan 2010 04:58:32 +0000

A website I built in 2009 for a family friend’s custom home construction business. The site was implemented using Wordpress, a paid theme, and a few helpful community plugins provided by the wordpress community.