Sunday, April 5, 2009

Software Development Process


A software development process is a structure imposed on the development of a software product. Synonyms include software life cycle and software process. There are several models for such processes, each describing approaches to a variety of tasks or activities that take place during the process.

Requirements analysis

The most important task in creating a software product is extracting the requirements or requirements analysis. Customers typically have an abstract idea of what they want as an end result, but not what software should do. Incomplete, ambiguous, or even contradictory requirements are recognized by skilled and experienced software engineers at this point. Frequently demonstrating live code may help reduce the risk that the requirements are incorrect.

Once the general requirements are gleaned from the client, an analysis of the scope of the development should be determined and clearly stated. This is often called a scope document. Certain functionality may be out of scope of the project as a function of cost or as a result of unclear requirements at the start of development. If the development is done externally, this document can be considered a legal document so that if there are ever disputes, any ambiguity of what was promised to the client can be clarified.

Domain Analysis is often the first step in attempting to design a new piece of software, whether it be an addition to an existing software, a new application, a new subsystem or a whole new system. Assuming that the developers (including the analysts) are not sufficiently knowledgeable in the subject area of the new software, the first task is to investigate the so-called "domain" of the software. The more knowledgeable they are about the domain already, the less work required. Another objective of this work is to make the analysts, who will later try to elicit and gather the requirements from the area experts, speak with them in the domain's own terminology, facilitating a better understanding of what is being said by these experts. If the analyst does not use the proper terminology it is likely that they will not be taken seriously, thus this phase is an important prelude to extracting and gathering the requirements. If an analyst hasn't done the appropriate work confusion may ensue: "I know you believe you understood what you think I said, but I am not sure you realize what you heard is not what I meant."[1]

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. A good way to determine whether the specifications are sufficiently precise is to have a third party review the documents making sure that the requirements and Use Cases are logically sound.

Architecture

The architecture of a software system or software architecture 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.

Design, implementation and testing

Implementation is the part of the process where software engineers actually program the code for the project.

Software testing is an integral and important part of the software development process. This part of the process ensures that bugs are recognized as early as possible.

Documenting the internal design of software for the purpose of future maintenance and enhancement is done throughout development. This may also include the authoring of an API, be it external or internal.

Deployment and maintenance

Deployment starts after the code is appropriately tested, is approved for release and sold or otherwise distributed into a production environment.

Software Training and Support is important because 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 often 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 new clients of your software.

Maintenance and enhancing software to cope with newly discovered problems or new requirements can take far more time than the initial development of the software. It may be necessary to add code that does not fit the original design to correct an unforeseen problem or it may be that a customer is requesting more functionality and code can be added to accommodate their requests. It is during this phase that customer calls come in and you see whether your testing was extensive enough to uncover the problems before customers do.

Certification

Professional certification of software engineers is a contentious issue. Some see it as a tool to improve professional practice; "The only purpose of licensing software engineers is to protect the public" [13]

The ACM had a professional certification program in the early 1980s,[citation needed] which was discontinued due to lack of interest. The ACM examined the possibility of professional certification of software engineers in the late 1990s, but eventually decided that such certification was inappropriate for the professional industrial practice of software engineering.[14] As of 2006, the IEEE had certified over 575 software professionals.[15] In Canada the Canadian Information Processing Society has developed a legally recognized professional certification called Information Systems Professional (ISP)[16]. The Software Engineering Institute offers certification on specific topic such as Security, Process improvement and Software architecture[17].

Most certification programs in the IT industry are oriented toward specific technologies, and are managed by the vendors of these technologies.[18] These certification programs are tailored to the institutions that would employ people who use these technologies.

Software engineering

Software engineering is the application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software, and the study of these approaches; that is, the application of engineering to software.[1]

The term software engineering first appeared in the 1968 NATO Software Engineering Conference and was meant to provoke thought regarding the current "software crisis" at the time.[2] Since then, it has continued as a profession and field of study dedicated to creating software that is of higher quality, cheaper, maintainable, and quicker to build. Since the field is still relatively young compared to its sister fields of engineering, there is still much work and debate around what software engineering actually is, and if it deserves the title engineering. It has grown organically out of the limitations of viewing software as just programming. Software development is a term sometimes preferred by practitioners in the industry who view software engineering as too heavy-handed and constrictive to the malleable process of creating software.

Yet, in spite of its youth as a profession, the field's future looks bright as Money Magazine and Salary.com rated software engineering as the best job in America in 2006.

Properties common to blueprints

Step-by-step procedure from blueprint to finished article

Software blueprinting processes advocate containing inspirational activity (problem solving) as much as possible to the early stages of a project in the same way that the construction blueprint captures the inspirational activity of the construction architect. Following the blueprinting phase only procedural activity (following prescribed steps) is required. This means that a software blueprint must be prescriptive and therefore exhibit the same formality as other prescriptive languages such as C++ or Java. Software blueprinting exponents claim that this provides the following advantages over enduring inspiration:

  • Potential for automatic machine translation to code
  • Predictable timescales after blueprinting phase
  • Software architect's intentions reflected directly in code

Focused on a single application aspect

Software blueprints focus on one aspect to avoid becoming diluted by compromising choice of description medium and to ensure that all of the relevant logic is localized.

Selection of optimal description medium

The single aspect focus of a software blueprint means that the optimal description medium can be selected. For example, algorithmic code may be best represented using textual code whereas GUI appearance may be best represented using a form design.

The motivation behind selecting an intuitive description medium (i.e. one that matches well with mental models and designs for a particular aspect) is to improve:

  • Ease of navigation
  • Ease of understanding
  • Fault detection rate
  • Ability to manage complexity

Localization of aspect logic

The localization of aspect logic promoted by the software blueprinting approach is intended to improve navigability and this is based on the assumption that the application programmer most commonly wishes to browse application aspects independently.

Orthogonalization

Software blueprinting relies on realizing a clean separation between logically orthogonal aspects to facilitate the localization of related logic and use of optimal description media described above.

Examples

GUI form design

The GUI form design (see GUI toolkit) is widely adopted across the software industry and allows the programmer to specify a prescriptive description of the appearance of GUI widgets within a window. This description can be translated directly to the code that draws the GUI (because it is prescriptive).

Machine translatable co-ordination languages (e.g. CDL)

Languages such as the Concurrent Description Language (CDL) separate an application's macroscopic logic (communication, synchronization and arbitration) from complex multi-threaded and/or multi-process applications into a single contiguous visual representation. The prescriptive nature of this description means that it can be machine translated into an executable framework that may be tested for structural integrity (detection of race conditions, deadlocks etc.) before the microscopic logic is available.

Class designers

Class designers allow the specification of arbitrarily complex data structures in a convenient form and the prescriptive nature of this description allows generation of executable code to perform list management, format translation, endian swapping and so on.

Software designers

Classes are used as building blocks by software designers to model more complex structures. In software architecture the Unified Modeling Language (UML) is an industry standard used for modeling the blueprint of software. UML represents structure, associations and interactions between various software elements, like classes, objects or components. It helps the software designer to design, analyze and communicate ideas to other members of the software community.

Software Blueprint

A software blueprint is the final product of a software blueprinting process. Its name derives from the analogy drawn with the popular use of the term blueprint (within traditional construction industry). Therefore, a true software blueprint should share a number of key properties with its building-blueprint counterpart:

SepaWeb

A comprehensive Web site has been developed to complement the content of the SEPA, 6/e. The Web site, called SepaWeb, provides a broad array of software engineering resources that will benefit instructors, students, and industry professionals.

Like all Web sites, SepaWeb will evolve over time, but the following major content areas will always be present:

(1) a broad array of instructor resources including a comprehensive on-line Instructor's Guide and supplementary teaching materials (e.g., slide presentations to supplement lectures);

(2) a wide variety of student resources including an extensive on-line learning center (encompassing study guides, problem solutions, web-based resources, a FAQ for each chapter, and self-tests), an evolving collection of "tiny tools," a case study, and additional supplementary content, and

(3) a detailed collection of professional resources including outlines (and samples of) software engineering documents and other work products, a useful set of software engineering checklists, a catalog of software engineering (CASE) tools, a comprehensive collection of web-based resources, and an "adaptable process model" that provides a detailed task breakdown of the software engineering process.
In addition, SepaWeb will contain other goodies that are currently in development.

Software Developer

A software developer is a person or organization concerned with facets of the software development process wider than design and coding, a somewhat broader scope of computer programming or a specialty of project managing including some aspects of software product management. This person may contribute to the overview of the project on the application level rather than component level or individual programming tasks. Software developers are often still guided by lead programmers but also encompasses the class of freelance software developers.

Other names which are often used in the same close context are software analyst and software engineer.

With time and a little luck, differences between system design, software development and programming are more apparent. Already in the current market place there can be found a segregation between programmers and developers, being that one who actually implements is not the same as the one who designs the class structure or hierarchy. Even more so that developers become systems architects, those who design the multi-leveled architecture or component interactions of a large software system.[1] (see also Debate over who is a software engineer)

A 'programmer' is responsible for writing code,[1] but a 'developer' could be involved in wider aspects of the software development process such as:

In a large company there may be employees whose sole responsibility may consist of only one of the phases above. In smaller development environments, a few, or even a single individual might handle the complete process.

Recent Tends in Sector

Given the rapid growth of this sector, several companies have started to use offshore development in China, India and other countries with a lower cost per developer model. Several new Web 2.0 platforms and sites are now developed offshore while management is located in Western countries. The advantages mostly revolve around better cost-control over the process, which means that there is lower cash-outflow (often the biggest struggle for startups). Furthermore, the time difference when working with India and China for the Western world allows work to be done round the clock adding a competitive advantage. Notable firms that are involved in development include Tata Consultancy Services, Infosys, Wipro, and Satyam

Software Development Methodology

A software development methodology is a framework that is used to structure, plan, and control the process of developing information systems. A wide variety of such frameworks have evolved over the years, each with its own recognized strengths and weaknesses. One system development methodology is not necessarily suitable for use by all projects. Each of the available methodologies is best suited to specific kinds of projects, based on various technical, organizational, project and team considerations.[4]

Testing

Testing is the process of examining a software product to find errors. This is necessary not just for code but for all life-cycle products and all documents in support of the software such as user manuals.

Coding Phase

The coding phase of the software life-cycle is concerned with the development of code that will implement the design. This code is written is a formal language called a programming language. Programming languages have evolved over time from sequences of ones and zeros directly interpretable by a computer, through symbolic machine code, assembly languages, and finally to higher-level languages that are more understandable to humans. See also Programming languages.

Design Phase

In the design phase, a plan is developed for how the system will implement the requirements. The plan is expressed using a design method and notation. Many methods and notations for software design have been developed. Each method focuses on certain aspects of a system and ignores or minimizes others. This is similar to viewing a building with an architectural drawing, a plumbing diagram, an electrical wiring diagram, and so forth.

Changlenges

To meet this challenge, software engineers have adapted many techniques from older engineering fields, as well as developing new ones. For example, divide and conquer, a well-known technique for handling complex problems, is used in many ways in software engineering. The software engineering process itself, for example, is usually divided into phases. The definition of these phases, their ordering, and the interactions between the phases specify a software life-cycle model. The best-known life-cycle model is the waterfall model consisting of a requirements definition phase, a design phase, a coding phase, a testing phase, and a maintenance phase. The output of each phase serves as the input to the next. See also Systems engineering.

Manufacturing

The process of manufacturing software systems. A software system consists of executable computer code and the supporting documents needed to manufacture, use, and maintain the code. For example, a word processing system consists of an executable program (the word processor), user manuals, and the documents, such as requirements and designs, needed to produce the executable program and manuals. See also Software engineering.

Software engineering is ever more important as larger, more complex, and life-critical software systems proliferate. The rapid decline in the costs of computer hardware means that the software in a typical system often costs more than the hardware it runs on. Large software systems may be the most complex things ever built. This places great demands on the software engineering process, which must be disciplined and controlled.

Requirement Phase

The purpose of the requirements phase is to define what a system should do and the constraints under which it must operate. This information is recorded in a requirements document. A typical requirements document might include a product overview; a specification of the development, operating, and maintenance environment for the product; a high-level conceptual model of the system; a specification of the user interface; specification of functional requirements; specification of nonfunctional requirements; specification of interfaces to systems outside the system under development; specification of how errors will be handled; and a listing of possible changes and enhancements to the system. Each requirement, usually numbered for reference, must be testable.

Software Engineering

(computer science) The systematic application of scientific and technological knowledge, through the medium of sound engineering principles, to the production of computer programs, and to the requirements definition, functional specification, design description, program implementation, and test methods that lead up to this code.

Papers and Columns in the January Issue

The January issue of SEN includes reports and papers on:

  • Creativity and Rationale in Software Design, by John Daughtry, Janet Burge, John M. Carroll, and Colin Potts
  • Fault Model and Test-Case Generation for the Composition of Aspects, by Chitra Babu and Harshini Ramnath Krishnany
  • Metrics to Study Symptoms of Bad Software Designs, by Kuljit Kaur Chahal and Hardeep Singh
  • Querying Complex Requirements, by Sergey Diev
  • Test Code Differencing for Test-Driven Refactoring Automation, by Hewijin Christine Jiau and Jinghong Cox Chen
  • Peer Review Assessment Standard for Object Oriented Analysis and Design, by Tony Lee
  • Managing Software Design Complexity: Facade vs Role-Based Design, by R. K. Pandey
  • Causal-Based Networks Supporting Process Improvement, by Karsten Richter
  • Software Maturity: Design as Dark Art, by Robert Schaefer
  • Application of Support Vector Machine to Predict Fault Prone Classes, by Yogesh Singh, Arvinder Kaur, and Ruchika Malhotra
  • ANN Model for Predicting Software Function Point Metric, by Yogesh Singh, Pradeep Kumar Bhatia, and Omprakash Sangwan
  • State Model Extraction of a Software Component by Observing its Behavior, by Rajiv Ranjan Suman and Rajib Mall

The letters and columns in the January issue include the following:

  • Letters from the Chair and the Editor
  • SIGSOFT Influential Educator Award

  • 25th ICSM in Edmonton
  • Membership Drive
  • Call For Nominations: 2009-2010 Athena Lecturer
  • ACM Lifetime Membership
  • The Philosophy of Computer Science
  • ACM TOSEM FAQs and Figures
  • SE Means Programming
  • Surfing and Risks to the Public