SAD Assignment 4: Systems Developemnt Models
{ Posted on 1:57 PM
by Ariel Serenado
}
Identify and discuss at least 3 systems development models …discuss each phase...
Systems Development Models are also referred as process models. In recent times, process models paved the way for the process of some projects involving information system implementation. The process models are typically used in structured analysis and design methods. The term process models are processes that are classified into a model. Thus, a process model is a description of a process. The same process is being used in repeatedly for the development of many applications and thus, has many instantiations. One possible use of a process model is to prescribe how things should be done as the process along through the documentation and finally into the development of the system or the project; also it is an anticipation of how process should look like. What the process shall be will be determined during actual system development. Moreover, the process model is typically used in structured analysis and design methods. Also, called a data flow diagram (DFD), it shows the flow of information through a system. Each process transforms input to outputs. Moreover, process models are not interchangeable since, the output of the first phase is the input of the succeeding phase. To deliver a quality system, it is critical to know the risks facing your project and to use a model that reduces those risks. The following describes standard project lifecycle models, and reviews their strengths and weaknesses. These standard models can be adapted to fit the industry issues, corporate culture, time constraints and team vulnerabilities which comprise your environment. The lifecycle model is a Process Model, however, there are many kinds of lifecycle models that use different strategies for building software. Your choice of lifecycle model should be based on how a particular model will work in your environment, or for a specific project; e.g. factors that affect choice of lifecycle model include how constrained the project schedule is, how well-known the requirements are, how sophisticated the team is, etc. Your ability to choose the most appropriate model requires that you know several models and the pros and cons of each: a particular model's effectiveness depends on the context in which it is used (McConnell 1996, p. 154).
To begin this assignment, there is a hundred of system development life cycle or what is also referred as process models. Some models do really have the same phases it differs only in the number of iterations, flexibility, and the approach to the system being developed. The following are the traditional and recently used systems development models or process models with strengths and weaknesses.
• Pure Waterfall
• Modified Waterfall
• Spiral
• Agile Software Development
• Extreme Programming
• Joint Application Development
• Design-to-Tools
• Rapid Application Development
• Scrum
Of all the process models, waterfall lifecycle is the most traditional of them all. This model has a top-down, or linear ordering to it. Normally, no phase is repeated, however, there may be overlapping between the different phases if necessary. Generally, the output of each stage is the input for the next. Waterfall has two types – pure waterfall and the modified waterfall.
Pure Waterfall
This is the classical system development model. It consists of discontinuous phases – Concept, Requirements, Architectural design, detailed design, Coding and Development, Testing and the Implementation. This kind of model works effectively to those projects with well defined and understood system requirements or in well understood technical tools. In general, its weakness is that pure waterfall is not advisable if rapid application is needle.
Strength: Structure lessens wasted effort, so it is convenient to those who are technically weak
Weakness: Not Flexible, the process should not be done up front.
Modified Waterfall
The modified waterfall use the same phases as the pure waterfall, but it is not done for a discontinuous basis. This enables the phases to overlap when added. This kind of model can split into subprojects at an appropriate phase. Flexible – risk reduction spirals can be added to the top of the waterfall to reduce risk prior to the waterfall phases. The model can be further modified using options as prototyping, JAD sessions or methods of requirements gathering done in overlapping places. Unforeseen interdependencies can create problems.
Spiral
This kind of model differs from waterfall cycle in terms of the linear approach. Some phases in the spiral are done repeatedly – phases such as planning, development, construction, and evaluation iterated until the development is done.
Strengths: The iterations enable the highest risks to be addresses at the lowest total cost. It is assumed that as the cost increases, risk decreases.
Weaknesses: It is complicated thus, requires attentive and knowledgeable management.
Agile Software Development
Agile methods generally promote a disciplined project management process that encourages frequent inspection and adaptation. It also refers to a group of software development methodologies based on the iterative development, where requirements and solutions evolve through collaboration between self organizing cross-functional teams.
Strengths: Minimizes feature creep by developing in short intervals resulting in miniature software projects mini-increments.
Weaknesses: Short iteration may not add enough functionality, leading to significant delays in final in final iterations. Agile method produces very little written documentation.
Extreme Programming
Extreme programming lowers the cost of changes through quick spirals of new requirements. However, programmers engaged in extreme programming are required to work in pairs which may be difficult for some developers which may result in more redesign effort in the long run.
Scrum
Is an iterative incremental framework for managing complex work, this is commonly used with agile software development. Although Scrum was intended for management of software development projects, it can be used to run software maintenance teams, or as s general project/program management approach.
Strength: The model allows you to prioritize work, completing items in a series of short iterations or sprints, daily measured progress and communication
Weaknesses: Its reliance o project teams and rejection of the traditional centralized process control may paralyze the team.
Evolutionary Prototyping
This model involves heavy user involvement while developers generate functional requirements and physical design specifications simultaneously. This model uses a lot of iterations; after each iteration, the result is analyzed by the customer. The response creates the next level of requirements an defines the next iteration.
Strength: The customer can see progress and can have the development monitoring. Useful when requirements are changing rapidly, when the customer is reluctant to a set of requirements.
Weaknesses: There is no way to know how much iteration to make. It is possible to know how long the project will take.
Rapid Application Development
This model focuses on building applications in a very short amount of time with comprise in usability, features, and/or execution speed. The emphasis on speed helps ensure that the client’ system requirements will not change as the process of development will start.
Strengths: Promotes strong collaboration and dynamic gathering of requirements. Clients are actively participating in prototyping, writing test cases and performing unit testing. RAD have the potential for providing a good framework for faster product development with enhanced code quality, but successful implementation and benefits often hinge on project type, schedule, software release and corporate culture.
Weaknesses: Dependency on cohesive teams and individual commitment to the project. Decision
making relies on the feature functionality.
Code and fix
If you don’t use methodology, it is likely you are doing code and fix. Code and fix rarely produces useful results. It is very dangerous as there is no way to assess progress, quality or risk.
Strengths: No time spent on overhead planning, documentation, quality assurance, standards enforcement or other non-coding activities.
Weaknesses: Fundamental flaws in approach do not show up quickly, often requiring work to be thrown out
Now, let’s discuss phases of some models.
The waterfall model is a sequential software development process, in which progress is seen as flowing steadily downwards (like a waterfall) through the phases of Conception, Initiation, Analysis, Design (validation), Construction, Testing and maintenance.
Feasibility
The feasibility study is used to determine if the project should get the go-ahead. If the project is to proceed, the feasibility study will produce a project plan and budget estimates for the future stages of development.
Requirement Analysis and Design
Analysis gathers the requirements for the system. This stage includes a detailed study of the business needs of the organization. Options for changing the business process may be considered. Design focuses on high level design like, what programs are needed and how are they going to interact, low-level design (how the individual programs are going to work), interface design (what are the interfaces going to look like) and data design (what data will be required). During these phases, the software's overall structure is defined. Analysis and Design are very crucial in the whole development cycle. Any glitch in the design phase could be very expensive to solve in the later stage of the software development. Much care is taken during this phase. The logical system of the product is developed in this phase.
Implementation
In this phase the designs are translated into code. Computer programs are written using a conventional programming language or an application generator. Programming tools like Compilers, Interpreters, Debuggers are used to generate the code. Different high level programming languages like C, C , Pascal, Java are used for coding. With respect to the type of application, the right programming language is chosen.
Testing
In this phase the system is tested. Normally programs are written as a series of individual modules, these subject to separate and detailed test. The system is then tested as a whole. The separate modules are brought together and tested as a complete system. The system is tested to ensure that interfaces between modules work (integration testing), the system works on the intended platform and with the expected volume of data (volume testing) and that the system does what the user requires (acceptance/beta testing).
Maintenance
Inevitably the system will need maintenance. Software will definitely undergo change once it is delivered to the customer. There are many reasons for the change. Change could happen because of some unexpected input values into the system. In addition, the changes in the system could directly affect the software operations. The software should be developed to accommodate changes that could happen during the post implementation period. You need to keep up with the project. In part this does mean that you should watch for bugs and other errors that are reported to you, and fix them. Yes, even your extensive testing regime may well have missed the odd issue here and there!
Just as importantly, though, is to keep developing the project. New ideas, new improvements, and simply bringing things up to date with the changing world (new currency for example!) are just as important to maintaining a project. Software and websites rarely need to die, as long as they are maintained. Look at everything from Windows to the Yahoo! website - the key to their longevity is that they are constantly renewed and updated. Keep the project fresh, relevant and useful, and it will survive.
It is a practice-based methodology for modeling and documentation of software-based systems. It is intended to be a collection of values, principles, and practices for modeling software that can be applied on a software development project in a more flexible manner than traditional modeling methods. The system development process is complicated and complex. Therefore maximum flexibility and appropriate control is required. Evolution favors those that operate with maximum exposure to environmental change and have optimized for flexible adaptation to change. Evolution deselects those who have insulated themselves from environmental change and have minimized chaos and complexity in their environment. An approach is needed that enables development teams to operate adaptively within a complex environment using imprecise processes. Complex system development occurs under rapidly changing circumstances. Producing orderly systems under chaotic circumstances requires maximum flexibility. The closer the development team operates to the edge of chaos, while still maintaining order, the more competitive and useful the resulting system will be. Langton has modeled this effect in computer simulations13 and his work has provided this as a fundamental theorem in complexity theory.
Characteristics of SCRUM methodology are:
• The first and last phases (Planning and Closure) consist of defined processes, where all processes, inputs and outputs are well defined. The knowledge of how to do these processes is explicit. The flow is linear, with some iteration in the planning phase.
• The Sprint phase is an empirical process. Many of the processes in the sprint phase are unidentified or uncontrolled. It is treated as a black box that requires external controls. Accordingly, controls, including risk management, are put on each iteration of the Sprint phase to avoid chaos while maximizing flexibility.
• Sprints are nonlinear and flexible. Where available, explicit process knowledge is used; otherwise tacit knowledge and trial and error is used to build process knowledge. Sprints are used to evolve the final product.
• The project is open to the environment until the Closure phase. The deliverable can be changed at any time during the Planning and Sprint phases of the project. The project remains open to environmental complexity, including competitive, time, quality, and financial pressures, throughout these phases.
SCRUM has the following groups of phases:
Pregame
• Planning : Definition of a new release based on currently known backlog, along with
an estimate of its schedule and cost. If a new system is being developed, this phase
consists of both conceptualization and analysis. If an existing system is being
enhanced, this phase consists of limited analysis.
• Architecture : Design how the backlog items will be implemented. This phase
includes system architecture modification and high level design.
Game
• Development Sprints : Development of new release functionality, with constant
respect to the variables of time, requirements, quality, cost, and competition.
Interaction with these variables defines the end of this phase. There are multiple,
iterative development sprints, or cycles, that are used to evolve the system.
Postgame
Closure : Preparation for release, including final documentation, pre-release staged
testing, and release.
Phase Steps
Each of the phases has the following steps:
Planning
• Development of a comprehensive backlog list.
• Definition of the delivery date and functionality of one or more releases.
• Selection of the release most appropriate for immediate development.
• Mapping of product packets (objects) for backlog items in the selected release.
• Definition of project team(s) for the building of the new release.
• Assessment of risk and appropriate risk controls.
• Review and possible adjustment of backlog items and packets.
• Validation or reselection of development tools and infrastructure.
• Estimation of release cost, including development, collateral material, marketing,
training, and rollout.
• Verification of management approval and funding.
Architecture/High Level Design
• Review assigned backlog items.
• Identify changes necessary to implement backlog items.
• Perform domain analysis to the extent required to build, enhance, or update the
domain models to reflect the new system context and requirements.
• Refine the system architecture to support the new context and requirements.
• Identify any problems or issues in developing or implementing the changes
• Design review meeting, each team presenting approach and changes to implement
each backlog item. Reassign changes as required.
Closure
When the management team feels that the variables of time, competition, requirements, cost, and quality concur for a new release to occur, they declare the release “closed” and enter this phase. This phase prepares the developed product for general release. Integration, system test, user documentation, training material preparation, and marketing material preparation are among closure tasks.
Rapid Application Development (RAD) refers to a type of software development methodology that uses minimal planning in favor of rapid prototyping. The "planning" of software developed using RAD is interleaved with writing the software itself. The lack of extensive pre-planning generally allows software to be written much faster, and makes it easier to change requirements
Below is a brief overview of the RAD process, which consists of four lifecycle stages: Requirements Planning, User Design, Construction, and Implementation. Also described are typical pre and post project activities.
The Gantthead project management portal is an excellent resource that contains more far more details on the process and additionally contains sample project plans and details on techniques such as time boxing, project estimation, recommended tools, and work breakdown structures. Do not begin your project without at least looking at this vital resource. Additional information is also available on the slightly dated but otherwise excellent website put together by Walter Maner of Bowling Green State University.
Pre-Project Activities
As with any project it is vital to identify the details of the project up front in some form of document such as a Project Management Plan (PMP). All parties should agree up front on details such as potential risks and mitigation strategies, a development schedule including resources, milestones and deliverables such as a completed data model or types of documentation to deliver, an approach including standards, tools, and technologies to be used, a desired end result, terms and constraints and financial considerations including budget and cost of tools.
Requirements Planning
The Requirements Planning stage (also known as the Concept Definition Stage) consists of meetings between a requirements planning team and key client users. Meetings focus on both developing a high level list of initial requirements as well as setting the project scope. The requirements planning team identifies primary business functions (such as "sell widgets to the Acme corporation") and initially breaks them down into business entities (such as Product, Sale, Company, Sales Person). The Requirements Planning stage should result in a list of entities as well as action diagrams that define the interactions between processes and data elements and should take between one and four weeks. Ideally requirements should be captured in a structured tool such as IBM's Rational Rose or Rational RequisitePro or Microsoft's Visio (the enterprise edition, since it can generate databases from a data model) rather than an unstructured document (see the tools section below for more details). At the end of the Requirements Planning stage project estimation should be considered. The International Function Point Users Group as well as the International Software Benchmarking Standards Group offer project estimation methods based on "function points" along with a vast database of actual projects with the effort involved to complete them.
User Design
During the User Design stage (also known as the Functional Design Stage) the analysis team meets with end users in Joint Application Development (JAD) Workshops. During the workshops the analysis team flushes out the requirements in more detail, develops the entities developed in the Requirements Planning into a data model (Entity Relationship Diagram), formalizes business rules, develops test plans, and creates screen flows and layouts for essential parts of the system. During the later half of the User Design stage the development team (also known as the SWAT or Skilled Workers with Advanced Tools team) aids the analysis team in activities such as creating a working data model that can be converted to a functional database, and in identifying reusable components (such as Microsoft's Application Blocks, which, incidentally, are an excellent time saver on Microsoft .Net projects). Again, as mentioned in the Requirements Planning stage, all requirements should be captured in a tool.
Before moving to the Construction Stage the analysis team should focus on next steps by flushing out the project plan and focusing on effort estimates. Focusing on next steps is an important element of the User Design phase, because the initial iteration of the Construction Phase should focus on a feature light prototype. In order to keep development iterations as short as possible, and to gain the maximum benefit of RAD's agile nature, core requirements should be identified and targeted for the initial prototype, and secondary requirements should be identified and targeted for future development iterations. Beyond a vertical limiting of scope, such as removing entities or use cases from the initial scope, a horizontal type limiting of scope should be considered as well, such as not developing field validation, not developing file upload/download capabilities, or focusing on just the strengths of the particular CASE tool being used without manually adding much developer customization.
The User Design stage should last between three and five weeks.
Construction
During the Construction Phase the Design Team develops the application in iterative cycles of development, testing, requirements refining, and development again, until the application is complete. Development iterations should last between one day and three weeks. The development team should convert the Data Model that was developed during the User Design Stage into a functional database (all data modeling tools have this ability). The CASE tool used (which may be the same as the data modeler or a separate tool) should now generate large sections of the application, at a minimum data access code, but preferably business functions and user interface as well.
At Automated Architecture, our Blue Ink product will read information from database that has been generated, pre-generate answers to meta-data about the project (in other words make a best guess as to the details of your application that you may then customize in more detail later), and generate an entire application that can serve as a working prototype without a line of development code. A prototype developed in this way may reduce the first iteration of development to days instead of weeks.
It is vital to keep each development iteration on track, and functionality may need to be dropped to keep development within the time box. Management plays a vital part in ensuring everything is progressing according to schedule, keeping the customer in the loop regarding changes in the functionality, and keeping the team motivated.
Once the prototype has been developed (within its time box), the construction team tests the initial prototype using test scripts developed during the User Design stage, the design team reviews the application, the customer reviews the application and finally the construction team, design team, and customer meet in Focus Group meetings in order to determine the requirements for the next iteration. Focus group meetings consist of facilitated sessions that last about two hours. The facilitator should know ahead of time the areas that require discussion and should ensure that each issue receives enough attention, keeping a list of issues that require additional attention in a separate meeting as appropriate.
After the meeting (additional meetings may be necessary), the development team and design team should update the requirements, data model, test scripts, and project plan as during the User Design stage. Again the teams should identify core and secondary requirements, plan out the next development iteration, keep the user in the loop regarding what will be done, and then start the next iteration of development over again. As the system approaches a sufficient state the development team should focus on the system as a finished application rather than a prototype.
During the final iterations of development the design team should update user documentation, perform User Acceptance Testing and define the steps necessary for deployment/implementation.
Implementation
The Implementation Stage (also known as the Deployment Stage) consists of integrating the new system into the business. The Development Team prepares data (such as lookup values like States and Countries) and implements interfaces to other systems. The Design Team trains the system users while the users perform acceptance testing. and are trained by the Design Team. The Design Team helps the users transfer from their old procedures to new ones that involve the new system, trouble shoots after the deployment, and identifies and tracks potential enhancements (read wish list). The amount of time required to complete the Implementation Stage varies with the project.
Post-Project Activities
As with any project final deliverables should be handed over to the client and such activities should be performed that will benefit future projects. Specifically it is a best practice for a Project Manager to review and document project metrics, organize and store project assets such as reusable code components, Project Plan, Project Management Plan (PMP), and Test Plan. It is also a good practice to prepare a short lessons learned document.
References:
http://www.blueink.biz/RapidApplicationDevelopment.aspx
http://acmesoffware.com/acme/default.asp
http://www.startvbdotnet.com/sdlc/sdlc.aspx
http://jeffsutherland.com/oopsla/schwapub.pdf
Systems Development Models are also referred as process models. In recent times, process models paved the way for the process of some projects involving information system implementation. The process models are typically used in structured analysis and design methods. The term process models are processes that are classified into a model. Thus, a process model is a description of a process. The same process is being used in repeatedly for the development of many applications and thus, has many instantiations. One possible use of a process model is to prescribe how things should be done as the process along through the documentation and finally into the development of the system or the project; also it is an anticipation of how process should look like. What the process shall be will be determined during actual system development. Moreover, the process model is typically used in structured analysis and design methods. Also, called a data flow diagram (DFD), it shows the flow of information through a system. Each process transforms input to outputs. Moreover, process models are not interchangeable since, the output of the first phase is the input of the succeeding phase. To deliver a quality system, it is critical to know the risks facing your project and to use a model that reduces those risks. The following describes standard project lifecycle models, and reviews their strengths and weaknesses. These standard models can be adapted to fit the industry issues, corporate culture, time constraints and team vulnerabilities which comprise your environment. The lifecycle model is a Process Model, however, there are many kinds of lifecycle models that use different strategies for building software. Your choice of lifecycle model should be based on how a particular model will work in your environment, or for a specific project; e.g. factors that affect choice of lifecycle model include how constrained the project schedule is, how well-known the requirements are, how sophisticated the team is, etc. Your ability to choose the most appropriate model requires that you know several models and the pros and cons of each: a particular model's effectiveness depends on the context in which it is used (McConnell 1996, p. 154).
To begin this assignment, there is a hundred of system development life cycle or what is also referred as process models. Some models do really have the same phases it differs only in the number of iterations, flexibility, and the approach to the system being developed. The following are the traditional and recently used systems development models or process models with strengths and weaknesses.
• Pure Waterfall
• Modified Waterfall
• Spiral
• Agile Software Development
• Extreme Programming
• Joint Application Development
• Design-to-Tools
• Rapid Application Development
• Scrum
Of all the process models, waterfall lifecycle is the most traditional of them all. This model has a top-down, or linear ordering to it. Normally, no phase is repeated, however, there may be overlapping between the different phases if necessary. Generally, the output of each stage is the input for the next. Waterfall has two types – pure waterfall and the modified waterfall.
Pure Waterfall
This is the classical system development model. It consists of discontinuous phases – Concept, Requirements, Architectural design, detailed design, Coding and Development, Testing and the Implementation. This kind of model works effectively to those projects with well defined and understood system requirements or in well understood technical tools. In general, its weakness is that pure waterfall is not advisable if rapid application is needle.
Strength: Structure lessens wasted effort, so it is convenient to those who are technically weak
Weakness: Not Flexible, the process should not be done up front.
Modified Waterfall
The modified waterfall use the same phases as the pure waterfall, but it is not done for a discontinuous basis. This enables the phases to overlap when added. This kind of model can split into subprojects at an appropriate phase. Flexible – risk reduction spirals can be added to the top of the waterfall to reduce risk prior to the waterfall phases. The model can be further modified using options as prototyping, JAD sessions or methods of requirements gathering done in overlapping places. Unforeseen interdependencies can create problems.
Spiral
This kind of model differs from waterfall cycle in terms of the linear approach. Some phases in the spiral are done repeatedly – phases such as planning, development, construction, and evaluation iterated until the development is done.
Strengths: The iterations enable the highest risks to be addresses at the lowest total cost. It is assumed that as the cost increases, risk decreases.
Weaknesses: It is complicated thus, requires attentive and knowledgeable management.
Agile Software Development
Agile methods generally promote a disciplined project management process that encourages frequent inspection and adaptation. It also refers to a group of software development methodologies based on the iterative development, where requirements and solutions evolve through collaboration between self organizing cross-functional teams.
Strengths: Minimizes feature creep by developing in short intervals resulting in miniature software projects mini-increments.
Weaknesses: Short iteration may not add enough functionality, leading to significant delays in final in final iterations. Agile method produces very little written documentation.
Extreme Programming
Extreme programming lowers the cost of changes through quick spirals of new requirements. However, programmers engaged in extreme programming are required to work in pairs which may be difficult for some developers which may result in more redesign effort in the long run.
Scrum
Is an iterative incremental framework for managing complex work, this is commonly used with agile software development. Although Scrum was intended for management of software development projects, it can be used to run software maintenance teams, or as s general project/program management approach.
Strength: The model allows you to prioritize work, completing items in a series of short iterations or sprints, daily measured progress and communication
Weaknesses: Its reliance o project teams and rejection of the traditional centralized process control may paralyze the team.
Evolutionary Prototyping
This model involves heavy user involvement while developers generate functional requirements and physical design specifications simultaneously. This model uses a lot of iterations; after each iteration, the result is analyzed by the customer. The response creates the next level of requirements an defines the next iteration.
Strength: The customer can see progress and can have the development monitoring. Useful when requirements are changing rapidly, when the customer is reluctant to a set of requirements.
Weaknesses: There is no way to know how much iteration to make. It is possible to know how long the project will take.
Rapid Application Development
This model focuses on building applications in a very short amount of time with comprise in usability, features, and/or execution speed. The emphasis on speed helps ensure that the client’ system requirements will not change as the process of development will start.
Strengths: Promotes strong collaboration and dynamic gathering of requirements. Clients are actively participating in prototyping, writing test cases and performing unit testing. RAD have the potential for providing a good framework for faster product development with enhanced code quality, but successful implementation and benefits often hinge on project type, schedule, software release and corporate culture.
Weaknesses: Dependency on cohesive teams and individual commitment to the project. Decision
making relies on the feature functionality.
Code and fix
If you don’t use methodology, it is likely you are doing code and fix. Code and fix rarely produces useful results. It is very dangerous as there is no way to assess progress, quality or risk.
Strengths: No time spent on overhead planning, documentation, quality assurance, standards enforcement or other non-coding activities.
Weaknesses: Fundamental flaws in approach do not show up quickly, often requiring work to be thrown out
Now, let’s discuss phases of some models.
waterfall model
The waterfall model is a sequential software development process, in which progress is seen as flowing steadily downwards (like a waterfall) through the phases of Conception, Initiation, Analysis, Design (validation), Construction, Testing and maintenance.
Feasibility
The feasibility study is used to determine if the project should get the go-ahead. If the project is to proceed, the feasibility study will produce a project plan and budget estimates for the future stages of development.
Requirement Analysis and Design
Analysis gathers the requirements for the system. This stage includes a detailed study of the business needs of the organization. Options for changing the business process may be considered. Design focuses on high level design like, what programs are needed and how are they going to interact, low-level design (how the individual programs are going to work), interface design (what are the interfaces going to look like) and data design (what data will be required). During these phases, the software's overall structure is defined. Analysis and Design are very crucial in the whole development cycle. Any glitch in the design phase could be very expensive to solve in the later stage of the software development. Much care is taken during this phase. The logical system of the product is developed in this phase.
Implementation
In this phase the designs are translated into code. Computer programs are written using a conventional programming language or an application generator. Programming tools like Compilers, Interpreters, Debuggers are used to generate the code. Different high level programming languages like C, C , Pascal, Java are used for coding. With respect to the type of application, the right programming language is chosen.
Testing
In this phase the system is tested. Normally programs are written as a series of individual modules, these subject to separate and detailed test. The system is then tested as a whole. The separate modules are brought together and tested as a complete system. The system is tested to ensure that interfaces between modules work (integration testing), the system works on the intended platform and with the expected volume of data (volume testing) and that the system does what the user requires (acceptance/beta testing).
Maintenance
Inevitably the system will need maintenance. Software will definitely undergo change once it is delivered to the customer. There are many reasons for the change. Change could happen because of some unexpected input values into the system. In addition, the changes in the system could directly affect the software operations. The software should be developed to accommodate changes that could happen during the post implementation period. You need to keep up with the project. In part this does mean that you should watch for bugs and other errors that are reported to you, and fix them. Yes, even your extensive testing regime may well have missed the odd issue here and there!
Just as importantly, though, is to keep developing the project. New ideas, new improvements, and simply bringing things up to date with the changing world (new currency for example!) are just as important to maintaining a project. Software and websites rarely need to die, as long as they are maintained. Look at everything from Windows to the Yahoo! website - the key to their longevity is that they are constantly renewed and updated. Keep the project fresh, relevant and useful, and it will survive.
Scrum Methodology
It is a practice-based methodology for modeling and documentation of software-based systems. It is intended to be a collection of values, principles, and practices for modeling software that can be applied on a software development project in a more flexible manner than traditional modeling methods. The system development process is complicated and complex. Therefore maximum flexibility and appropriate control is required. Evolution favors those that operate with maximum exposure to environmental change and have optimized for flexible adaptation to change. Evolution deselects those who have insulated themselves from environmental change and have minimized chaos and complexity in their environment. An approach is needed that enables development teams to operate adaptively within a complex environment using imprecise processes. Complex system development occurs under rapidly changing circumstances. Producing orderly systems under chaotic circumstances requires maximum flexibility. The closer the development team operates to the edge of chaos, while still maintaining order, the more competitive and useful the resulting system will be. Langton has modeled this effect in computer simulations13 and his work has provided this as a fundamental theorem in complexity theory.
Characteristics of SCRUM methodology are:
• The first and last phases (Planning and Closure) consist of defined processes, where all processes, inputs and outputs are well defined. The knowledge of how to do these processes is explicit. The flow is linear, with some iteration in the planning phase.
• The Sprint phase is an empirical process. Many of the processes in the sprint phase are unidentified or uncontrolled. It is treated as a black box that requires external controls. Accordingly, controls, including risk management, are put on each iteration of the Sprint phase to avoid chaos while maximizing flexibility.
• Sprints are nonlinear and flexible. Where available, explicit process knowledge is used; otherwise tacit knowledge and trial and error is used to build process knowledge. Sprints are used to evolve the final product.
• The project is open to the environment until the Closure phase. The deliverable can be changed at any time during the Planning and Sprint phases of the project. The project remains open to environmental complexity, including competitive, time, quality, and financial pressures, throughout these phases.
SCRUM has the following groups of phases:
Pregame
• Planning : Definition of a new release based on currently known backlog, along with
an estimate of its schedule and cost. If a new system is being developed, this phase
consists of both conceptualization and analysis. If an existing system is being
enhanced, this phase consists of limited analysis.
• Architecture : Design how the backlog items will be implemented. This phase
includes system architecture modification and high level design.
Game
• Development Sprints : Development of new release functionality, with constant
respect to the variables of time, requirements, quality, cost, and competition.
Interaction with these variables defines the end of this phase. There are multiple,
iterative development sprints, or cycles, that are used to evolve the system.
Postgame
Closure : Preparation for release, including final documentation, pre-release staged
testing, and release.
Phase Steps
Each of the phases has the following steps:
Planning
• Development of a comprehensive backlog list.
• Definition of the delivery date and functionality of one or more releases.
• Selection of the release most appropriate for immediate development.
• Mapping of product packets (objects) for backlog items in the selected release.
• Definition of project team(s) for the building of the new release.
• Assessment of risk and appropriate risk controls.
• Review and possible adjustment of backlog items and packets.
• Validation or reselection of development tools and infrastructure.
• Estimation of release cost, including development, collateral material, marketing,
training, and rollout.
• Verification of management approval and funding.
Architecture/High Level Design
• Review assigned backlog items.
• Identify changes necessary to implement backlog items.
• Perform domain analysis to the extent required to build, enhance, or update the
domain models to reflect the new system context and requirements.
• Refine the system architecture to support the new context and requirements.
• Identify any problems or issues in developing or implementing the changes
• Design review meeting, each team presenting approach and changes to implement
each backlog item. Reassign changes as required.
Closure
When the management team feels that the variables of time, competition, requirements, cost, and quality concur for a new release to occur, they declare the release “closed” and enter this phase. This phase prepares the developed product for general release. Integration, system test, user documentation, training material preparation, and marketing material preparation are among closure tasks.
Rapid Application Development (RAD)
Rapid Application Development (RAD) refers to a type of software development methodology that uses minimal planning in favor of rapid prototyping. The "planning" of software developed using RAD is interleaved with writing the software itself. The lack of extensive pre-planning generally allows software to be written much faster, and makes it easier to change requirements
Below is a brief overview of the RAD process, which consists of four lifecycle stages: Requirements Planning, User Design, Construction, and Implementation. Also described are typical pre and post project activities.
The Gantthead project management portal is an excellent resource that contains more far more details on the process and additionally contains sample project plans and details on techniques such as time boxing, project estimation, recommended tools, and work breakdown structures. Do not begin your project without at least looking at this vital resource. Additional information is also available on the slightly dated but otherwise excellent website put together by Walter Maner of Bowling Green State University.
Pre-Project Activities
As with any project it is vital to identify the details of the project up front in some form of document such as a Project Management Plan (PMP). All parties should agree up front on details such as potential risks and mitigation strategies, a development schedule including resources, milestones and deliverables such as a completed data model or types of documentation to deliver, an approach including standards, tools, and technologies to be used, a desired end result, terms and constraints and financial considerations including budget and cost of tools.
Requirements Planning
The Requirements Planning stage (also known as the Concept Definition Stage) consists of meetings between a requirements planning team and key client users. Meetings focus on both developing a high level list of initial requirements as well as setting the project scope. The requirements planning team identifies primary business functions (such as "sell widgets to the Acme corporation") and initially breaks them down into business entities (such as Product, Sale, Company, Sales Person). The Requirements Planning stage should result in a list of entities as well as action diagrams that define the interactions between processes and data elements and should take between one and four weeks. Ideally requirements should be captured in a structured tool such as IBM's Rational Rose or Rational RequisitePro or Microsoft's Visio (the enterprise edition, since it can generate databases from a data model) rather than an unstructured document (see the tools section below for more details). At the end of the Requirements Planning stage project estimation should be considered. The International Function Point Users Group as well as the International Software Benchmarking Standards Group offer project estimation methods based on "function points" along with a vast database of actual projects with the effort involved to complete them.
User Design
During the User Design stage (also known as the Functional Design Stage) the analysis team meets with end users in Joint Application Development (JAD) Workshops. During the workshops the analysis team flushes out the requirements in more detail, develops the entities developed in the Requirements Planning into a data model (Entity Relationship Diagram), formalizes business rules, develops test plans, and creates screen flows and layouts for essential parts of the system. During the later half of the User Design stage the development team (also known as the SWAT or Skilled Workers with Advanced Tools team) aids the analysis team in activities such as creating a working data model that can be converted to a functional database, and in identifying reusable components (such as Microsoft's Application Blocks, which, incidentally, are an excellent time saver on Microsoft .Net projects). Again, as mentioned in the Requirements Planning stage, all requirements should be captured in a tool.
Before moving to the Construction Stage the analysis team should focus on next steps by flushing out the project plan and focusing on effort estimates. Focusing on next steps is an important element of the User Design phase, because the initial iteration of the Construction Phase should focus on a feature light prototype. In order to keep development iterations as short as possible, and to gain the maximum benefit of RAD's agile nature, core requirements should be identified and targeted for the initial prototype, and secondary requirements should be identified and targeted for future development iterations. Beyond a vertical limiting of scope, such as removing entities or use cases from the initial scope, a horizontal type limiting of scope should be considered as well, such as not developing field validation, not developing file upload/download capabilities, or focusing on just the strengths of the particular CASE tool being used without manually adding much developer customization.
The User Design stage should last between three and five weeks.
Construction
During the Construction Phase the Design Team develops the application in iterative cycles of development, testing, requirements refining, and development again, until the application is complete. Development iterations should last between one day and three weeks. The development team should convert the Data Model that was developed during the User Design Stage into a functional database (all data modeling tools have this ability). The CASE tool used (which may be the same as the data modeler or a separate tool) should now generate large sections of the application, at a minimum data access code, but preferably business functions and user interface as well.
At Automated Architecture, our Blue Ink product will read information from database that has been generated, pre-generate answers to meta-data about the project (in other words make a best guess as to the details of your application that you may then customize in more detail later), and generate an entire application that can serve as a working prototype without a line of development code. A prototype developed in this way may reduce the first iteration of development to days instead of weeks.
It is vital to keep each development iteration on track, and functionality may need to be dropped to keep development within the time box. Management plays a vital part in ensuring everything is progressing according to schedule, keeping the customer in the loop regarding changes in the functionality, and keeping the team motivated.
Once the prototype has been developed (within its time box), the construction team tests the initial prototype using test scripts developed during the User Design stage, the design team reviews the application, the customer reviews the application and finally the construction team, design team, and customer meet in Focus Group meetings in order to determine the requirements for the next iteration. Focus group meetings consist of facilitated sessions that last about two hours. The facilitator should know ahead of time the areas that require discussion and should ensure that each issue receives enough attention, keeping a list of issues that require additional attention in a separate meeting as appropriate.
After the meeting (additional meetings may be necessary), the development team and design team should update the requirements, data model, test scripts, and project plan as during the User Design stage. Again the teams should identify core and secondary requirements, plan out the next development iteration, keep the user in the loop regarding what will be done, and then start the next iteration of development over again. As the system approaches a sufficient state the development team should focus on the system as a finished application rather than a prototype.
During the final iterations of development the design team should update user documentation, perform User Acceptance Testing and define the steps necessary for deployment/implementation.
Implementation
The Implementation Stage (also known as the Deployment Stage) consists of integrating the new system into the business. The Development Team prepares data (such as lookup values like States and Countries) and implements interfaces to other systems. The Design Team trains the system users while the users perform acceptance testing. and are trained by the Design Team. The Design Team helps the users transfer from their old procedures to new ones that involve the new system, trouble shoots after the deployment, and identifies and tracks potential enhancements (read wish list). The amount of time required to complete the Implementation Stage varies with the project.
Post-Project Activities
As with any project final deliverables should be handed over to the client and such activities should be performed that will benefit future projects. Specifically it is a best practice for a Project Manager to review and document project metrics, organize and store project assets such as reusable code components, Project Plan, Project Management Plan (PMP), and Test Plan. It is also a good practice to prepare a short lessons learned document.
References:
http://www.blueink.biz/RapidApplicationDevelopment.aspx
http://acmesoffware.com/acme/default.asp
http://www.startvbdotnet.com/sdlc/sdlc.aspx
http://jeffsutherland.com/oopsla/schwapub.pdf
No Response to "SAD Assignment 4: Systems Developemnt Models"
Post a Comment