Software Engineering

Overlaps the other book: Introduction to Software Engineering

The idea of this book is to couple together the different projects on the different subjects of software engineering. Currently the only book linked is Computer Programming. Other subjects should be added over time.

As written in the Computer Programming book, coding is only a small part of software engineering. This book is intended as an introduction to the realm of software engineering.

The Basics

What is software engineering?

A systematic approach to the analysis, design, implementation and maintenance of software.

Software engineering is the engineering discipline through which software is developed. Commonly the process involves finding out what the client wants, composing this in a list of requirements, designing an architecture capable of supporting all of the requirements, designing, coding, testing and integrating the separate parts, testing the whole, deploying and maintaining the software. Programming is only a small part of software engineering.

The discipline is still in its infancy (early stage of growth/development) as an engineering discipline. We haven't had enough experience, nor gathered enough empirical data to systematically understand and predict the life-cycle of a software project.

The Software Engineering Body of Knowledge (SWEBOK) divides software engineering into 10 knowledge areas:

1. Software requirements
2. Software design
3. Software construction
4. Software testing
5. Software maintenance
6. Software configuration management
7. Software engineering management
8. Software engineering process
9. Software engineering tools and methods
10. Software quality

The content of the field

Note: the following summaries are originally from Wikipedia. These are here only temporarily. The titles aren't final, nothing on this page is final yet (or even near final).

Vision and Scope

The practice of software engineering in the corporate or industrial sector, starts with the business and ends with the business. Although computers, programming languages, and creative problem solving are what fill the engineer with interest in the field, without servicing and enabling the user, the exercise would be pointless. Thus the first stage in any software engineering process, is the Vision and Scope document, or some equivalent meeting.

A vision of the system to be built is described by the user or Product Champion. The business context that it will service is described. The key stakeholders are enumerated including their interests, risks, etc. The success conditions are listed, so that it is understood what will be completed and how to measure success.

Business opportunities are discussed, to justify why the project should be invested with the blood, sweat, and tears of programmers, testers, project managers, and program managers. The Scope of the project is made clear and if it is to be in phases, the scope of each phase at a high level is laid out. The priorities of the project are recorded.

With an understanding of the business' vision, the engineers begin to ask questions.

Requirements Analysis

Extracting requirements of a desired software product is the first task in creating it. This process is called requirements elicitation. While customers probably believe they know what the software should do, it may require skill and experience in software engineering to recognize incomplete, ambiguous or contradictory requirements.

Compounding this problem is the absence of formal abstractions. A civil, mechanical engineer has a plan, elevation, sections to refer to and these make good sense to both the author and reader of these abstractions. However, while (E-R) or object diagrams, process flow diagrams, data flow diagrams are abstractions that have been used and built on, many of these are not universally used or practiced.

Besides, considerable effort goes into repairing and enhancing existing systems. Engineering required here is a mix of reverse and forward engineering in the sense that requirements definitions refer to a set of circumstances that already exist and these circumstances have to be stated in unambiguous terms as well.

Perhaps, lack of universally accepted abstractions make life difficult for software engineers and some people have even argued that software production process is closer to art rather than engineering!

Of late, people have started using prototypes in various degrees of working. Screen shots and report layouts are non working prototypes and form the basic level of prototyping and increasing sophistication is built in wherever possible. Making prototypes is always more time consuming than not making one. Thus, this practice is not always utilised.

Analyst Role

The role of analyst can be fulfilled typically by three types of people. A technical project manager, a software engineer, or a dedicated analyst. In some organizations it is unthinkable to engineers that they would serve the analyst role, as they are "technical" and would consider dealing directly with the customer unthinkable. This is purely a cultural stance that varies between companies and organizations. It is also quite common for software engineers to work closely with the business people and customers associated with a project, and this programmer/analyst role can be quite beneficial to the projects success rate.

As you are gathering requirements, you can subject them to analysis. Does the requirement in question conflict with others? What is its priority? Where did it come from? Does it need further clarification?

Analysis is the ability to draw inferences from requirements and represent them in a structured way. Structures themselves may vary based on what is being analysed. It is very tough to draw boundaries between analysis and requirements gathering as they both use the same abstractions many a time.

One could argue that analysis yields data storage structures and workflow structures etc. However, one would think that these are not the only outputs from analysis.

Communication Techniques

The common technique that means the software requirement analysis begins with communication between two or more parties. Review of a software requirement specification is conducted by both software developer and customer. Because the specification forms the foundation for design and subsequent software engineering activities, extreme care should be taken in conducting the review. The review is first conducted at a macroscopic level. At this level, the reviewers attempt to ensure that the specification is complete, consistent and accurate. Once the review is complete a software requirement specification is signed off, “by both customers and developer”.

Case Study

While requirement analysis phase some problems are come. The problems are identified and defined and listed here. • The problem occurs that did exist in smaller systems, which leads to a redefining of priority of the activities that go into developing software. • In the beginning of the requirements phase, the needs of clients are in the minds of various people in the client organization. • The major role of the problem statement is that the customer has a problem that may be responsible to a computer-based solution. A developer responds to the customer’s request for help. Here the one more problem is the path from communication to understanding is often full of difficulties.

Suggestions

The above case study/problem determined while requirement analyzing phase in "system engineering". This page can be improved soon. --Ananthakumar Selvaraj (discuss • contribs) 13:02, 18 March 2013 (UTC)

Use Cases

Once the vision and scope of a engineering project has been established the requirements gather process begins. One tool for communicating between the customer, analyst, developers, and testers is a set of Use Cases. A Use Case typically has a name, a short description, and then a number set of steps which a user would go through to accomplish a task. Use cases are sometimes grouped together in a UML or other format of diagram depicting users, the system, external entity and specific use cases.

Granularity

Use Cases are typically coarse-grained and don't dive into every detail and functional requirement of the system. A business person or software engineer should be able to read through all of the use cases and get an idea of the entire scope of what the project will deliver.

Formality of Use Cases

Agile driven projects may skip these cases, or at least only record the attributes discussed above. Plan driven methodologies may give additional attributes to Use Cases such as alternative paths after covering the main steps, trace requirements covered by the use case back to their source, and have an error handling section for each use case.

THE STAGES OF ANALYSIS

Analysis is typically accomplished in two stages. The first stage, Business Analysis includes an in-depth examination of the customer's present set of business or manufacturing processes and procedures with an eye toward how they might be improved by automation. The second stage, Systems Analysis consists of an examination of the proposed improvements and a recommendation on what computer environment and software technology is best suited to accomplish those improvements.

BUSINESS ANALYSIS STAGE

From the Business Analyst's in-depth understanding of the customer's present environment, he or she creates a set of "business use-cases", which are short descriptions of the role that each of the business's "actors" perform within each process or procedure. For instance, the waiter in a restaurant might have a use case as follows: " A. Actor approaches customer table, introduces self and recites a description of the day's specials. B. Actor presents a beverage menu and inquires if customer would like to order a beverage. C. If yes, actor writes each customer's order on a drink tag and proceeds to bar area. D. Actor presents the tag to bar-keep and makes a mental note to check back within a customary time to see if the drink order is complete. E. If no, Actor presents a dinner menu and helps customers to make selections. As each new party of customers is seated, actor repeats procedure, beginning from step A." With a set of raw use-cases like the proceeding, the business analyst can, with the customer's collaboration, examine how each use-case might be automated and can thereby define an official system requirement which becomes one of maybe hundreds of requirements that define the future software application. As might be surmised, the effective Business Analyst must not only have extensive experience with and knowledge of the business world, but must also have expertise in the potentialities offered by modern software systems and how those systems map to the reality of the business world.

SYSTEMS ANALYSIS STAGE

The second stage of the analysis process, Systems Analysis begins from the foundation laid by the business analyst. From the set of business use cases and their resultant software requirements, the Systems Analyst makes recommendations as to the most suitable software technology to accomplish those requirements. In some cases, the hardware environment limits choices of software technologies. For instance, in the restaurant scenario, above. The customer might be adamant about providing the waiter with a handheld device to replace the drink tag and to make the trip to the bar unnecessary before the drink order is ready to serve. In such a case, the systems analyst might be constrained to using only those operating systems and APIs that are supported on the preferred handheld device.

Once the programming and run-time environment is decided, then the systems analyst can begin turning the business use-cases and requirements into a set of "system use-cases," which are descriptions of how the actors will interact with the proposed system. Those system use-cases, taken together now comprise the actual blueprint that will be used by software architects to begin laying out the classes or other software modules that will define a road map for the software coding and development process which follows.

Specification

Specification is the task of precisely describing the software to be written, in a mathematically rigorous way. In reality, most successful specifications are written to understand and fine-tune applications that were already well-developed. Specifications are the most important for external interfaces that must remain stable.

Requirements Management

Once you have gathered requirements, captured them into a specification, and the customer agrees with it, it is possible to take a snapshot or baseline of the project requirements. This allows one to manage existing requirements and process new incoming ones. The specification is placed under configuration management, such as a tool like CVS so that the requirements can be versioned and tracked.

Rejecting Requirements

It is important to reject requirements that

• Don't fit within the project scope
• Cannot show a positive return on investment
• Won't make the system competitive
• Aren't technically feasible

A requirement rejected doesn't have to be further analyzed, implemented, documented, or tested. Every requirement costs the company and must be thought through.

Change Control

Regardless of whether your methodology is agile or plan driven, you should create some form of change control to process new requirements. Failure to do so may lead to project failure due to scope creep, project overruns, poor quality, or high costs. Change control can be as simple as a development manager reviewing specification, to an elaborate tool supported process with forms and a board of people with change control authority.

Lack of communication about changes to a specification can lead to costly wasted work by developers, testers, or analysts. The time it takes to change one requirement in a specification, may cost 100 times the person hours to realize the decision.

Design and Architecture

Design and architecture are the activities involved in specifying how the software will actually work. This phase frequently described as being divided into two main phases, which might be described as "business design" and "technical design". Business design generally specifies the "why" of the system, indicating how data will be used and how it will flow. Technical design generally specifies the "how" of the system, or how its components will be arranged, what their features will be, and what kind of hardware the system will require. These two phases can often be conducted roughly simultaneously, with business design usually starting first and technical design ending last.

Of all of the phases, the design phase can often consume the most time, and many engineers consider it the most important. A poor design can cause the failure of a project, even after considerable resources are spent during the construction phase of the project building it. It is important for the design and architecture of the system to be complete enough that it can be validated and then used to develop the system.

Coding

Reducing a design to code may be the most obvious part of the software engineering process, but it is not necessarily the largest portion. In fact, many software engineers only work on the analysis and design process, then the coding work is handed off to computer programmers to implement. This trend is increasing in many companies, where software engineers are hired domestically and the implementation is out-sourced to a country where programming labor is less expensive. In spite of this trend, many software engineers still go through the entire process and do coding as well as design.

Coding Wikibook

Testing

The purpose of testing is not only to prove that the code performs in accordance with the design specifications, but to prove that it does not fail when subjected to undefined inputs.

There are several types of testing. Unit testing tests one module of code for correct inputs, outputs, and functionality. System testing tests all the modules of a software system together. User acceptance testing is a form of systems testing to see if not only the system works, but it meets the requirements of the business user. Regression testing is testing performed after a system change to make sure that all system features are still present after the change.

To perform systems and verifications testing, Use cases are developed. These cases describe a user action or a specific feature of the system. These cases are very useful during the construction phase of the system, and are usually specified as a deliverable of the design phase. The use cases are generally gathered into test scripts which describe testing activities in a reproducible way. These scripts may be executed manually by testers, or they may be executed by automated testing software.

Generally speaking, it is an accepted industry practice for system testing and validation to be performed by a separate person, team, or department, or in some cases, by an outside entity. Testing is considered a specialized skill, with a skill set that is very different from system development. It also is generally considered a bad practice for software developers to test their own systems, since they can form habits that do not exercise the system thoroughly, and because they can frequently test around system failures.

There are different kinds of testing such as white box testing or black box testing.

Documentation

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

Software documentation is important. Without documentation, software can be unusable, because the end user does not know how to operate a program. Without documentation, an application can be incorrectly installed on a server, causing components to fail. Documentation is most important for external interfaces.

There are several means by which software can be documented, including flowcharts, deployment guides, user's manuals, and maintenance manuals.

Development team members may write their own documentation, or a professional technical writer may write or edit the documents for readability and style.

It's important to note that testing is or should be done during or at the end of every stage. If this is not done, inputs into the next stage can not be very complete. Documentation may also be sketchy or none existent.

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 2/3 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. Similarly, about 2/3 of all civil engineering, architecture, and construction work is maintenance in a similar way.

Applied Software Engineering

The process of software engineering differs between different software types. Building a word processor has different requirements and design methods than building a 3D first person shooter. These sections cover the differences and unique properties of the different software types.

SE on Server Software

Software engineering for server software is more complex then development for the desktop computers. A server is more complex, has more requirements and features than an ordinary, consumer system. Server software can have client-server as well as central architecture. Development and testing of server software is also different from the development and testing of the desktop software. Not every programming language is suitable for implementation of server software. In conclusion, SE on server software requires special methods and processes to successfully complete.

The main reason server software is more complex is that communication between 2 computers -- the server and the client -- is inherently more complex and prone to failure than communication between parts of a program running on a single computer.

SE on Simulations

Games

Designing software for gaming simulations can be quite challenging, since it requires a diverse background in software. For example, a game designer might have to write software that simulates physics as well as software that renders 3-dimensional images. However, many software engineers in the gaming industry are able to use 3rd party engines that make their job much easier. Nonetheless, they must follow the software engineering process closely, since small issues in the software can make the product fail in the consumer market. Writing software for games is a high-risk industry and only a small percentage of games are financially successful.

SE on Embedded software

Software engineers that work with embedded computer systems need more knowledge of hardware than most software engineers, since embedded systems typically introduce more constraints on memory availability and processing power than, say, gaming PCs. Designing software for embedded systems can indeed be challenging, since most embedded processors cannot handle the overhead produced by compiling high-level languages. This often forces software engineers to implement embedded software, at least partially, in assembly.