Exposition
In the article, there are a number of Software Engineering approaches that have been carried out throughout the software development process. In this section I would like to give a brief explanation about the approaches and terms that have been used.
The mentioned approaches are as follows:
1 Incremental Approach
The Incremental Approach is one of the Software Process Models. This model combines the elements of the linear sequential model which is applied repetitively with the iterative philosophy of prototyping. Each linear sequence will produce a deliverable “increment” of software.
In the Linear Approach, software development is carried out in a systematic, sequential approach which begins at the system level and progresses through analysis, design, coding, testing, and support.
The first increment is often a core product, i.e. the basic requirements are addressed, but many supplementary features remain undelivered. The core product is used by the customer or undergoes detailed review. As the result of use or evaluation, a plan is developed for the next increment. The plan addresses the modification of the core product to better meet the needs of the customer and the delivery of additional features and functionality. The process is repeated following the delivery of each increment, until the complete product is produced.
2 Software Engineering Institute Capability Maturity Model (SEI CMM)
This is a comprehensive model predicated on a set of software engineering capabilities that should be present as organizations reach different levels of process maturity. Capability Maturity Model (CMM) defines key activities required at different level of process maturity and provides a measure of the global effectiveness of a company’s software engineering practices and establishes five process maturity levels that are defined in the following manner:
The software process is characterized as ad hoc, and occasionally even chaotic. Few processes are defined, and success depends on individual effort and heroics.
Basic project management processes are established to track cost, schedule, and functionality. The necessary process discipline is in place to repeat earlier successes on projects with similar applications.
The software process for both management and engineering activities is documented, standardized, and integrated into a standard software process for the organization. All projects use an approved, tailored version of the organization's standard software process for developing and maintaining software.
Detailed measures of the software process and product quality are collected. Both the software process and products are quantitatively understood and controlled.
Continuous process improvement is enabled by quantitative feedback from the process and from piloting innovative ideas and technologies.
There area associated Key Process Areas (KPA) with each of the maturity levels. The KPA are additive in nature. The details of the KPA will not be discussed here and can be found at reference 2 and at SEI website at reference 3.
3 Object Oriented Methodology and CRC Card
Object Oriented is a software development approach whereby noun phrases that satisfied certain requirements will be treated as object. Object-oriented methodology has defined profound stages for this process - Object Analysis, Object Design, Object Construction and Object Management. These four stages are not exactly sequential steps like the traditional "waterfalls", where projects move from request to requirement definition to design to coding, testing, implementation and maintenance. Object Oriented stages are iterative processes and interactive to each other. Things are not built according to some master plan from very beginning, but piece by piece, organically.
1. Object Analysis
The first and most profound stage requires the adoption of a new Object-oriented analysis paradigm, which addresses how the basic building blocks of systems are defined, not as data and procedures, but in larger, more self-contained entities that are based on the principles of encapsulation, inheritance and polymorphism. In this stage, the documents like System Boundary Diagrams, External Actor Descriptions and Use Cases can be constructed for the verification of the high-level modules (via role-playing) and for the validation of the functional requirements (via acceptance testing).
2. Object Design
Object design takes the information from the process of Object Analysis to find the domain objects, define the appropriate responsibilities for each domain object and prepare the transition from analysis phase to actual development. Object Design plays very critical role in the whole process. Good design promotes reusability, modularity, maintainability, faster implementation, higher performance and lower resource requirements.
In this stage, CRC Cards and Design Patterns can be used to assist on finding the domain objects. Model structure diagram should be constructed to capture the relationship of all domain objects. Message flow diagrams/Object Interaction Diagrams can be used for the verification of the model structure of the new system. Developers should work very closely to agree upon the model structure and public interface for each domain object.
3. Object Construction
Once the design is agreed upon, the classes can be assigned to different developers and coded independently. In this stage, code-reviews by domain experts of class detail designs and method implementations should be done periodically. Test plans should be constructed. Developers will also work closely with the end users on data presentation (screens) and user's acceptance.
4. Object Management
This stage requires the establishment of a fundamental aspect -- the object repository -- that becomes the wellspring for all future development. It contains deliberately constructed or acquired objects that are generic ideally to the whole organization. Object Management also has to address many organizational issues like version control, coding style and standards, procedures for deployment, documentation and training, etc.
The CRC Card Method extends the knowledge of OO and used them to identify classes, responsibilities and collaborations between the objects in an object-oriented system. The 4 main steps in the CRC Card methods are Identifying Objects, Identifying Operations, Identifying Relationships, and Developing Scenarios. For more information please refer to reference 12
4 Unified Modeling Language (UML)
UML is a general-purpose notational language for specifying and visualizing complex software, especially large, object-oriented projects. UML defines twelve types of diagrams, divided into three categories: Four diagram types represent static application structure; five represent different aspects of dynamic behavior; and three represent ways you can organize and manage your application modules.
Modeling is the designing of software applications before coding. Modeling is an essential part of large software projects, and helpful to medium and even small projects as well. A model plays the analogous role in software development that blueprints and other plans (site maps, elevations, physical models) play in the building of a skyscraper. Using a model, it can assure that business functionality is complete and correct, end-user needs are met, and program design supports requirements for scalability, robustness, security, extendibility, and other characteristics, before implementation in code renders changes difficult and expensive to make.
5 Computer-Aided Software Engineering (CASE) Tools
a category of software that provides a development environment for programming teams. CASE systems offer tools to automate, manage and simplify the development process. These can include tools for:
Various companies offer CASE software capable of supporting some or all of these activities. While many CASE systems provide special support for object-oriented programming, the term CASE can apply to any type of software development environment.