Software development process means how software is developed from start to finish in a broad sense. Software projects usually start with some fuzzy requirements. The requirements are then studied thoroughly and based on the requirements the software is designed and then coded or implemented and then tested and finally the software is released or deployed when the maintenance phase starts. These phases are done iteratively, most of the time. The Augmented Waterfall Process model presents these phases in a simplified manner as shown in Figure 1.
If the dotted upward arrows are removed from Figure 1 then the classical waterfall model would be represented without any iteration. The classical waterfall model is often criticized by software engineers because it cannot accomodate changes in the process and the requirements analysis is frozen at some point in the development pocess. Boehm (1986) proposed a process model that is more comprehensive and more realistic about changes in the software development process. Boehm's spiral model is presented in Figure 2.
Agile software process is the most flexible process model (Pressman & Maxim 2014) which allows major changes to process plans. An agile software process adapts to changing technical and project conditions.
Assume that a software project started with the following initial description of requirements: Develop a software system for computing volume of two types of storage units: box-storage and cylinder-storage. Users should be able to enter input interactively using a Graphical User Interface (GUI).
After studying requirements, software engineers would discover that the system has to be web-based and it should be available 24/7. Users should be able to access the software without any login ID. It should be easy to maintain by an administrator. The software engineers then would prepare a software requirements specification (SRS) document. A modern requirements analysis is typically use case driven (Leffingwell & Widrig 2003). A use case diagram is drawn with UML notations. A use case diagram for the storage volume problem is given in Figure 3.
A General Interface View is proposed.
The General Interface View includes Interface Diagrams that are not shown here.
An Interface Diagram may include screen shots, screen elements or their represntations.
The General Interface View and the UML Use Case View together model the aspects of all interfaces including user interfaces and actor interfaces.
A Use Case Operational Diagram can be drawn for each use case which will present operational aspects of the use case. Figure 4 presents a use case Operational Diagram for the box storage volume use case. Alternatively, a use case can be represented by an Activity Diagram as suggested by Pressman & Maxim (2014)
The software would then be desgined based on the requirements analysis. "Software design is an iterative process through which requirements are translated into a "blueprint" for constructing the software." (Pressman 2005, page 229). The design
is described with some UML diagrams. UML diagrams are the most popular
design diagrams at this time. The class diagram given in Figure 5 presents
some static aspects of the software using the generalization and association relationships. The generalization relationship is recommended when subclasses (or sub-categories) of a class can be identified.
Design tools based on statecharts (Harel, 1987; Harel and Politi, 1998) have been very useful for modeling dynamic aspects of software. Statecharts are basically Turing Machines presented in a notation that is appropriate for representing software features in an intuitive way. The following statechart diagram represents the dynamic aspects of computing
volume of box-storage and cylinder-storage units.
Boehm B,(1986) "A Spiral Model of Software Development and Enhancement", ACM SIGSOFT Software
Engineering Notes", "ACM", 11(4):14-24.
Brooks, F. (1995) The Mythical Man Month, Addison-Wesley.
Deitel, H. M. & Deitel, P. J. (2009) Java How to Program, 8th Edition, Prentice-Hall
Eeles, P. & Crips, P. (2009) The Process of Software Architecting, Addison-Wesley.
Harel, D. (1987) �Statecharts: A visual formalism for complex systems�, Science of
Computer Programming, v.8 n.3, p.231-274, 1987
Harel, D. & Politi, M. (1998) Modeling Reactive Systems with Statecharts: The Statemate
Leffingwell, D. & Widrig, D. (2003) Managing Software Requirements: A Use Case Approach, 2nd ed. Addison-Wesley.
Pressman, Roger S. (2005) Software Engineering: A Practitioner�s Approach, 6th Ed. McGraw-Hill.
Pressman, Roger S. & Maxim, B. (2014) Software Engineering: A Practitioner�s Approach, 8th Ed. McGraw-Hill.
Rumbaugh, R., Jacobson, I. & Booch, G. (2005) The Unified Modeling Language Reference Manual.
2nd Edition, Addison Wesley.
Shneiderman, B., Plaisant, C., Cohen, M. & Jacobs, S. (2009) Designing the User Interface: Strategies for Effective Human-Computer Interaction
(5th Edition), Prentice Hall, 2009.
Sommerville, Ian (2011) Software Engineering, 9th Ed., Addison-Wesley.
Agile Process (n.d.) Manifesto for Agile Software Development http://agilemanifesto.org/
For questions and comments, please contact:Dr. Pradip Peter Dey, Professor, School of Engineering and Technology National University 3678 Aero Court, San Diego, CA 92123 U.S.A. Phone: (858) 309-3421 Fax (858) 309-3420 Email: email@example.com