http://blog.teachbook.com.au

The system development life cycle (SDLC) is the traditional approach taken to systems development. It is a phased or stepped approach.

The SDLC is really a project management tool or a way of sequencing the tasks that need to be carried out to develop a new information system.

• the investigation phase results in the requirements of the new system coming to light
• the analysis phase sees the detailed investigation of the existing system
• the design phase sees the new system designed to meet the requirements that came to light in the investigation phase.
• the new system is brought on line during the implementation phase
• finally, the new system is examined for its effectiveness during the review phase

If the problem exist with the new system then the entire process or part thereof may have to be repeated – hence the term life cycle.

Software Development Methodologies (SDM)

Software engineering is the practice of using selected process techniques to improve the quality of a software development effort. This is based on the assumption, subject to endless debate and supported by patient experience, that a methodical approach to software develop results in fewer defects and, therefore, ultimately provides shorter delivery times and better value. The documented collection of policies, processes and procedures used by a development team or organization to practice software engineering is called its software development methodology (SDM) or system development lifecycle (SDLC)

Software Development Process

The software development process, also known as the software development lifecyle, is structure imposed on the development of a software product. Similar terms include software lifecycle and software process. There are several models and methodologies for such processes, each describing approaches to a variety of tasks or activities that take place during the process. Some people consider a lifecycle model more general term and a software development process a more specific term. For example, there are many specific software development processes that ‘fit’ the spiral lifecycle model.

Planning

The important task in creating a software product is extracting the requiremenbts 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 recognised by skilled and experienced software engingers at this point.

Implementing, testing and documenting

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 defects 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 writing of an API, be it external or internal. It is very important to document everything in the project.

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 and a lot of developers fail to realise that. It would not 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 development phase, it is very important to have training classes for new clients of your software.

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. It may be necessary to add code that does not fit the original design to correct an unforseen problem or it may be that a custoemr is requesting more functionality and code can be added to accomodate thier requests. If the labor costs of the maintenance phases exceeds 25% of the prior-phases’ labor costs, then it is likely that the overall quality of at least one prior phase is poor. In that case, management should consider the option of rebuilding the system (or portions) before maintenance cost is out of control.

Protoyping and Rapid application design

Prototyping is not an alternative to the traditional approach of the SDLC, by an aid generally used during the design phase. Prototyping is based on an engineering approach whereby small scale models are built; these help end-users define their requirements and preferred input-output interface.

Rapid application design (RAD) involves regular meetings between systems developers and system users with the aim of rapidly developing a prototype of the information system until the users are statisfied with capabilities and ‘look’ of the system. Again this methodology is not an alternative to the SDLC, but a way of quickly developing the user interfaces and has largely arisen because of the development of software tools that now make this possible.

Comparison of Methodologies

A methodology is the strategies employed by the systems analyst during the various phases of the SDLC. There are are a number of different types of methodology. The more traditional approach has been the structured approach; this methodology grew up alongside the structured programming techniques that were introduced to bring some standardisation to the programming task. An alternative approach, that of object orientation, has grown up alongside the object-oriented approach to programming.

Structured Techniques

This is the modelling approach that builds models of the processes (data flow diagrams) for a system. In this approach the data is considered a separate entity to the processes that manipulate the data.

<example of a structured model>

Different modelling tools are then used to describe the data and the relationships between the data. These structured techniques are the basis of our studies in this module.

Object-oriented techniques

The object-oriented approach to system development is emerging as an alternative to the traditional methods of structured systems development. The object-oriented approach blends the processes and the data that those processes are operating on and treats them as one.

Models of Information Systems

Why create a model?

A model describes the information system as it is, or will be, implemented by the users; it is in a graphical form. Models are a graphical method of representing a system rather than a narrative method ("a picture paints a thousand words"). Building models of information system helps analysts clarify whether or not they have accounted for all aspects of the system.

If you were an architect designing a building you would construct a series of drawings: one showing room dimensions, one showing the plumbing required and one showing the electrical wiring. As a system analyst you will construct a series of models depicting different aspects of the information system:

• a data flow diagram to show the processes carried out
• entity-relationship diagrams to describe the relationships within the data
• a data dictionary to describe the data used by the system and so on.

Physical and Logical Models

A physical model descibes how the job is or will be done and concentrates on the physical components: namely the people, the forms, the files and so on.

A logical model is an abstraction of the system and highlights the data content of a system. The logical aspects are those elements that are the same whether the work is done by pen and paper or by computer. The logical model does not tell us how things are done, or by whom.

Types of Modelling Tools

A variety of structured modelling tools are used by systems analysts at different phases of the systems development process to describe different aspects of the ifnormation system being developed.

• Context diagrams These show an overview of the information system: more specifically they are used to help identify the scope of the information system, the people (or other information systems) that interact with the information system being analysed and the specific flow of information making up this interaction.
• Data flow diagrams – Data flow diagrams (DFDs) model the processes and files that make up the information system. They also show the data that flows between them.
• Data Dictionaries – These describe or model the elements of data used by the information system.
• Entity-Relationship Diagrams - Entity-relationship (E-R) diagrams are models or graphical representations of the relationships that exist between the data in the information system.
• System Flow Charts – These show the sequence of steps through which the data passes and the various formats that the data takes (stored on disk or tape, displayed as output to the screen or printed as a report) as well as whether the processes are manual or automated. A system flow chart is a physical modelling tool.
• Hierarchy Charts – These show the logical relationships between the modules and the flow of data between the modules. A structure chart is really a hierarchy chart with data flows.
• Structure Charts – These show the logical relationships between the modules and the flow of data between the modules. A strucutre chart is really a hierarchy chart with data flows.
• Input-processing-output charts – Input-processing-output (IPO) charts describe each processing module. They show the inputs to and the outputs from the module as well as the detailed processing required within it.
• Hierarchy input-processing-output charts – Hierarchy input-processing-ouput (HIPO) charts show the relationships between modules (hierarchy chart) as well as the detail of inputs, processing and outputs within a module (IPO).
• Process specification tools – These are useful for specifying the logic of the individual processing modules. They are then used by programmers as a basis for writing the individual program modules. Process specification tool include:
  • structured English/pseudocode
  • Nassi-Schneidermann Charts
  • Program Flow Chart
  • Decision Trees

These modelling techniques are described in greater detail in later units.