Software Elements Analysis

The most important task in creating a software product is extracting the requirements. Customers typically know what they want, but not what software should do, while incomplete, ambiguous or contradictory requirements are recognized by skilled and experienced software engineers. Frequently demonstrating live code may help reduce the risk that the requirements are incorrect.

Specification

Specification is the task of precisely describing the software to be written, possibly in a rigorous way. In practice, most successful specifications are written to understand and fine-tune applications that were already well-developed, although safety-critical software systems are often carefully specified prior to application development. Specifications are most important for external interfaces that must remain stable.

Software architecture

The architecture of a software system refers to an abstract representation of that system. Architecture is concerned with making sure the software system will meet the requirements of the product, as well as ensuring that future requirements can be addressed. The architecture step also addresses interfaces between the software system and other software products, as well as the underlying hardware or the host operating system.

Implementation (or coding)

Reducing a design to code may be the most obvious part of the software engineering job, but it is not necessarily the largest portion.

Testing

Testing of parts of software, especially where code by two different engineers must work together, falls to the software engineer.

Documentation

An important (and often overlooked) task is documenting the internal design of software for the purpose of future maintenance and enhancement. Documentation is most important for external interfaces.

Software Training and Support

A large percentage of software projects fail because the developers fail to realize that it doesn’t matter how much time and planning a development team puts into creating software if nobody in an organization ends up using it. People are occasionally resistant to change and avoid venturing into an unfamiliar area so, as a part of the deployment phase, it is very important to have training classes for the most enthusiastic software users, shifting the training towards the neutral users intermixed with the avid supporters, and finally incorporate the rest of the organization into adopting the new software. Users will have lots of questions and software problems which leads to the next phase of software.

Maintenance

Maintaining and enhancing software to cope with newly discovered problems or new requirements can take far more time than the initial development of the software. Not only may it be necessary to add code that does not fit the original design but just determining how software works at some point after it is completed may require significant effort by a software engineer. About 60% of all software engineering work is maintenance, but this statistic can be misleading. A small part of that is fixing bugs. Most maintenance is extending systems to do new things, which in many ways can be considered new work.

Waterfall processes

The best-known and oldest process is the waterfall model, where developers (roughly) follow these steps in order:

· state requirements

· analyze requirements

· design a solution approach

· architect a software framework for that solution

· develop code

· test (perhaps unit tests then system tests)

· deploy

· post-implementation.

After each step is finished, the process proceeds to the next step, just as builders don’t revise the foundation of a house after the framing has been erected. There is a misconception that the process has no provision for correcting errors in early steps (for example, in the requirements). In fact this is where the domain of requirements management comes in which includes change control. This approach is used in high risk projects, particularly large defense contracts. The problems in waterfall do not arise from “immature engineering practices, particularly in requirements analysis and requirements management”. Studies of the failure rate of the DOD-STD-2167 specification, which enforced waterfall, have shown that the more closely a project follows its process, specifically in up-front requirements gathering, the more likely the project is to release features that are not used in their current form.

Iterative processes

Iterative development prescribes the construction of initially small but ever larger portions of a software project to help all those involved to uncover important issues early before problems or faulty assumptions can lead to disaster. Iterative processes are preferred by commercial developers because it allows a potential of reaching the design goals of a customer who does not know how to define what they want.

Agile software development processes are built on the foundation of iterative development. To that foundation they add a lighter, more people-centric viewpoint than traditional approaches. Agile processes use feedback, rather than planning, as their primary control mechanism. The feedback is driven by regular tests and releases of the evolving software.

Agile processes seem to be more efficient than older methodologies, using less programmer time to produce more functional, higher quality software, but have the drawback from a business perspective that they do not provide long-term planning capability. However, polls show gains, sometimes significant.

Among other interesting improvements reported were:

· Enhanced ability to manage changing priorities

· Alignment between IT and business goals

· Improved team morale

· Reduced project risk

There is also an interesting chart at http://versionone.com/Resources/ AgileBenefits.asp that shows Agile development value proposition in comparison to traditional development.

Extreme Programming, XP, is the best-known iterative process. In XP, the phases are carried out in extremely small (or “continuous”) steps compared to the older, “batch” processes. The (intentionally incomplete) first pass through the steps might take a day or a week, rather than the months or years of each complete step in the Waterfall model. First, one writes automated tests, to provide concrete goals for development. Next is coding (by a pair of programmers), which is complete when all the tests pass, and the programmers can’t think of any more tests that are needed. Design and architecture emerge out of refactoring, and come after coding. Design is done by the same people who do the coding. (Only the last feature - merging design and code - is common to all the other agile processes.) The incomplete but functional system is deployed or demonstrated for (some subset of) the users (at least one of which is on the development team). At this point, the practitioners start again on writing tests for the next most important part of the system.

Test Driven Development (TDD) is a useful output of the Agile camp but raises a conundrum. TDD requires that a unit test be written for a class before the class is written. Therefore, the class firstly has to be “discovered” and secondly defined in sufficient detail to allow the write-test-once-and-code-until-class-passes model that TDD actually uses. This is actually counter to Agile approaches, particularly (so-called) Agile Modeling, where developers are still encouraged to code early, with light design. Obviously, to get the claimed benefits of TDD, a full design down to class and responsibilities (captured using, for example, Design By Contract) is necessary. This counts towards iterative development, with a design locked down, but not iterative design - as heavy refactoring and re-engineering negate the usefulness of TDD.

While iterative development approaches have their advantages, software architects are still faced with the challenge of creating a reliable foundation upon which to develop. Such a foundation often requires a fair amount of up-front analysis and prototyping to build a development model. The development model often relies upon specific design patterns and entity relationship diagrams (ERD). Without this upfront foundation, iterative development can create long term challenges that are significant in terms of cost and quality.

Critics of iterative development approaches point out that these processes place what may be an unreasonable expectation upon the recipient of the software: that they must possess the skills and experience of a seasoned software developer. The approach can also be very expensive if iterations are not small enough to mitigate risk; akin to... “If you don’t know what kind of house you want, let me build you one and see if you like it. If you don’t, we’ll tear it all down and start over”. By analogy the critic argues that up-front design is as necessary for software development as it is for architecture. The problem with this criticism is that the whole point of iterative programming is that you don’t have to build the whole house before you get feedback from the recipient. Indeed, in a sense conventional programming places more of this burden on the recipient, as the requirements and planning phases take place entirely before the development begins, and testing only occurs after development is officially over.

In fact, a relatively quiet turn around in the Agile community has occurred on the notion of “evolving” the software without the requirements locked down. In the old world this was called requirements creep and never made commercial sense. The Agile community has similarly been “burnt” because, in the end, when the customer asks for something that breaks the architecture, and won’t pay for the re-work, the project terminates in an Agile manner.

These approaches have been developed along with web based technologies. As such, they are actually more akin to maintenance life cycles given that most of the architecture and capability of the solutions is embodied within the technology selected as the back bone of the application.

4. Answer the questions to the text:

1. What is the idea behind Test Driven Development?

2. What are the main benefits of using Agile Methods?

3. What is the main aim of introducing the SPICE standard?

4. What is the aim of utilizing the Six Sigma methodology, and how can it help the performance of some kinds of companies?

5. Which of the software development steps involve most contact with the customer? (possible topic for discussion)

6. What kind of project often requires the use of the Waterfall Process of software development?

7. What is the function of requirements management, mentioned in reference to the Waterfall Process?

8. With reference to Iterative processes, what is agile development mainly based on?

9.What condition must the coding process fulfil before it can be completed?

5. Work in two teams: A/B. Group A are the customers, group B the developers:

ü Imagine how the iterative process of development works on any application (e.g. building a house) and simulate it. Prepare a very short report which sums up the negotiations between the teams.

ü Prepare a comparison between Iterative and Waterfall processes. Write it down in table form. Focusing on the differences, answer the following questions:

1. Which features of these techniques do you think are better?

2. Do you use any of them? Which ones and why?

6. Discuss the following questions:

1. Do you agree with the critics of the iterative processes?

2. What are the steps of software development that are indispensable for creating a good academic project?

3. Imagine that you are the manager of a team of several people. Write the outline of a project that you have heard about during your studies. How would you divide the work within your team to make the final product perfect?