right2670041Software Development Methodology00Software Development Methodology1682755034347Name |Course Title| Date950000Name |Course Title| DateActivity 1In order to ensure team members and your line manager have a greater understanding of the role of methodologies in software development produce an easy to use reference guide which provides:an explanation of the differences between system and application softwarean evaluation of software development methodologiesan explanation of the phases of software development. Support your explanation with examplesDifferences Between System and Application SoftwareBelow are the differences between system and application software:System Software Application SoftwareDefinitionThe System Software is a general purpose software and is essential for the working of the computer. Generally, the end user does not interact with the System Software directly. The user interacts with the GUI created by System Software. The Application Software runs on the platform created by the System Software. Application Software is an intermediary between the end user and System Software.
You can install multiple Application Software on a System Software. Application Software is not essential to run a system, but it makes the system useful.PurposeSystem Software is general-purpose. Application Software is specific-purpose.
BasicSystem Software manages system resources and provides a platform for application software to run. Application Software, when run, perform specific tasks, they are designed for.LanguageSystem Software is written in a low-level language, i.e. assembly language. Application Software is written in a high-level language like Java, C++, .net, VB, etc.
InstallationSystem software is installed on the computer when the operating system is installed. Application software is installed according to user’s requirements.Execution TimeIt can be executed when required. It is executed every time on the computer.RunSystem Software starts running when the system is turned on and runs until the system is shut down. Application Software runs as and when the user requests.RequirementA system is unable to run without system software. Application software is even not required to run the system; it is user specific.
Interaction In general, the user does not interact with the system software because it works in the background. In general, the user interacts with application software.UseSystem software is used for operating computer hardware. Application software is used by the user to perform a specific task.ExampleThe operating system, compiler, assembler, debugger, driver, etc. word processor, web browser, media player, Microsoft Office, Photoshop, Animation Software, etc.ConclusionBoth, the System Software and the Application Software together make a system useful for the end user.
The System Software is compulsory for the system to work. Similarly, the Application Software is necessary for the user to perform their specific task.Evaluation of Software Development MethodologiesBelow is the Evaluation of Software Development Methodologies:Introduction Advantages DisadvantagesWaterfall software development methodology.The Waterfall Model was the first Process Model to be introduced. It is also referred to as a linear-sequential life cycle model. It is very simple to understand and use. In a waterfall model, each phase must be completed before the next phase can begin and there is no overlapping in the phases.
The Waterfall model is the earliest SDLC approach that was used for software development. The waterfall Model illustrates the software development process in a linear sequential flow. This means that any phase in the development process begins only if the previous phase is complete. In this waterfall model, the phases do not overlap. Some of the major advantages of the Waterfall Model are as follows Simple and easy to understand and useEasy to manage due to the rigidity of the model. Each phase has specific deliverables and a review process.Phases are processed and completed one at a time.
Works well for smaller projects where requirements are very well understood.Clearly defined stages.Well understood milestones.Easy to arrange tasks.
Process and results are well documented. The major disadvantages of the Waterfall Model are as followsNo working software is produced until late during the life cycle.High amounts of risk and uncertainty.Not a good model for complex and object-oriented projects.Poor model for long and ongoing projects.Not suitable for the projects where requirements are at a moderate to high risk of changing. So, risk and uncertainty are high with this process model.
It is difficult to measure progress within stages.Cannot accommodate changing requirements.Adjusting scope during the life cycle can end a project.Integration is done as a “big-bang. at the very end, which doesn’t allow for identifying any technological or business bottleneck or challenges early.Spiral methodology.
The spiral model combines the idea of iterative development with the systematic, controlled aspects of the waterfall model. This Spiral model is a combination of iterative development process model and sequential linear development model i.e. the waterfall model with a very high emphasis on risk analysis. It allows incremental releases of the product or incremental refinement through each iteration around the spiral. The advantages of the Spiral SDLC Model are as follows Changing requirements can be accommodated.
Allows extensive use of prototypes.Requirements can be captured more accurately.Users see the system early.Development can be divided into smaller parts and the risky parts can be developed earlier which helps in better risk management.
The disadvantages of the Spiral SDLC Model are as follows ?Management is more complex.End of the project may not be known early.Not suitable for small or low-risk projects and could be expensive for small projects.Process is complexSpiral may go on indefinitely.Large number of intermediate stages requires excessive documentation.Agile software development methodology.Agile model believes that every project needs to be handled differently and the existing methods need to be tailored to best suit the project requirements. In Agile, the tasks are divided into time boxes (small time frames) to deliver specific features for a release.
An iterative approach is taken and working software build is delivered after each iteration. Each build is incremental in terms of features; the final build holds all the features required by the customer. The advantages of the Agile Model are as follows It is a very realistic approach to software development.Promotes teamwork and cross-training.Functionality can be developed rapidly and demonstrated.Resource requirements are minimum.
Suitable for fixed or changing requirementsDelivers early partial working solutions.A good model for environments that change steadily.Minimal rules, documentation easily employed.
Easy to manage. The disadvantages of the Agile Model are as follows Not suitable for handling complex dependencies.More risk of sustainability, maintainability, and extensibility.An overall plan, an agile leader, and agile PM practice is a must without which it will not work.
Strict delivery management dictates the scope, functionality to be delivered, and adjustments to meet the deadlines.Depends heavily on customer interaction, so if the customer is not clear, the team can be driven in the wrong direction.There is a very high individual dependency since there is minimal documentation generated.
Rapid application development methodology (RAD).The RAD (Rapid Application Development) model is based on prototyping and iterative development with no specific planning involved. The process of writing the software itself involves the planning required for developing the product. Rapid Application Development focuses on gathering customer requirements through workshops or focus groups, early testing of the prototypes by the customer using iterative concept, reuse of the existing prototypes (components), continuous integration and rapid delivery.
The advantages of the RAD Model are as follows Changing requirements can be accommodated.Progress can be measured.Iteration time can be short with the use of powerful RAD tools.
Productivity with fewer people in a short time.Reduced development time.Increases reusability of components.Quick initial reviews occur.Encourages customer feedback.Integration from the very beginning solves a lot of integration issues. The disadvantages of the RAD Model are as follows Dependency on technically strong team members for identifying business requirements.
The only system that can be modularized can be built using RAD.Requires highly skilled developers/designers.High dependency on modeling skills.Inapplicable to cheaper projects as the cost of modeling and automated code generation is very high.
Management complexity is more.Suitable for systems that are component based and scalable.Rational unified process methodology (RUP).The Rational Unified Process methodology main aim to capture the software development in a single combined package. RUP also maintains an iterative model method, where a manager of the project can take into justification the altering project necessities and propose adjustments as required. All the elements of the project are combined gradually over time, permitting investors sufficient period to perfect the software, besides all risks are talked concluded addition can be moderated initially throughout the development time. RUP similarly inspires software module to recycle for fast development times, and meanwhile, faults are modified over the period of numerous repetitions, the end result is healthy software lacking any performance blocks This is a complete methodology in itself with an emphasis on accurate documentationIt is proactively able to resolve the project risks associated with the client’s evolving requirements requiring careful change request managementLess time is required for integration as the process of integration goes on throughout the software development lifecycle.The development time required is less due to the reuse of components.
There are online training and tutorial available for this process. The team members need to be expert in their field to develop a software under this methodology.The development process is too complex and disorganized.On cutting edge projects which utilize new technology, the reuse of components will not be possible. Hence the time saving one could have made will be impossible to fulfill.Integration throughout the process of software development, in theory, sounds a good thing. But on particularly big projects with multiple development streams, it will only add to the confusion and cause more issues during the stages of testingJoint application development Methodology (JAD).
The JAD methodology main stress on a collaboration of the client- developer for design and development of the software. This is done with workshops help which are JAD meetings, where the main purpose is on commercial difficulties as a substitute of on the practical particulars. JAD is not for appropriate method for business development systems its aim is to reduce costs by decreasing the downstream variations The advantages of the JAD Model are as follows Complimentary skills – you are having 2 different set of skillsUsually, the outcome is a better-quality productUsually, the progress is fasterAccountability: pushing each other to work faster, deliver on time, do what you say The disadvantages of the JAD Model are as follows Revenue sharingDifferent opinions – you have to align your goals and focusYou learn at a different speed and pay attention to different thingsDifferent work schedules and prioritiesPhases of Software DevelopmentBelow are the Phases of Software Development:SDLC is a process followed for a software project, within a software organization. It consists of a detailed plan describing how to develop, maintain, replace and alter or enhance the specific software. The life cycle defines a methodology for improving the quality of software and the overall development process.
Stage DescriptionPlanning and Requirement AnalysisRequirement analysis is the most important and fundamental stage in SDLC. It is performed by the senior members of the team with inputs from the customer, the sales department, market surveys and domain experts in the industry. This information is then used to plan the basic project approach and to conduct product feasibility study in the economic, operational and technical areas. Planning for the quality assurance requirements and identification of the risks associated with the project is also done in the planning stage. The outcome of the technical feasibility study is to define the various technical approaches that can be followed to implement the project successfully with minimum risks.Defining Requirements Once the requirement analysis is done the next step is to clearly define and document the product requirements and get them approved by the customer or the market analysts. This is done through an SRS (Software Requirement Specification) document which consists of all the product requirements to be designed and developed during the project life cycle.Designing the Product Architecture SRS is the reference for product architects to come out with the best architecture for the product to be developed.
Based on the requirements specified in SRS, usually, more than one design approach for the product architecture is proposed and documented in a DDS – Design Document Specification. This DDS is reviewed by all the important stakeholders and based on various parameters as risk assessment, product robustness, design modularity, budget and time constraints, the best design approach is selected for the product. A design approach clearly defines all the architectural modules of the product along with its communication and data flow representation with the external and third-party modules (if any). The internal design of all the modules of the proposed architecture should be clearly defined with the minutest of the details in DDS.Building or Developing the Product In this stage of SDLC, the actual development starts and the product is built. The programming code is generated as per DDS during this stage. If the design is performed in a detailed and organized manner, code generation can be accomplished without much hassle.
Developers must follow the coding guidelines defined by their organization and programming tools like compilers, interpreters, debuggers, etc. are used to generate the code. Different high-level programming languages such as C, C++, Pascal, Java, and PHP are used for coding. The programming language is chosen with respect to the type of software being developed.Testing the Product This stage is usually a subset of all the stages as in the modern SDLC models, the testing activities are mostly involved in all the stages of SDLC.
However, this stage refers to the testing the only stage of the product where product defects are reported, tracked, fixed and retested, until the product reaches the quality standards defined in the SRS.Deployment in the Market and Maintenance Once the product is tested and ready to be deployed it is released formally in the appropriate market. Sometimes product deployment happens in stages as per the business strategy of that organization. The product may first be released in a limited segment and tested in the real business environment (UAT- User acceptance testing). Then based on the feedback, the product may be released as it is or with suggested enhancements in the targeting market segment. After the product is released on the market, its maintenance is done for the existing customer base.Activity 2Using the scenario provided, design an information system for a mobile attendance application. Choose a suitable software development methodology to use during the design phase and justify why you have chosen this methodology.
Produce a comprehensive evaluation of the chosen selected software development methodology, identifying strengths and areas for improvement.Suitable software development methodologyFor the development of software, we will use the waterfall model. Waterfall model is a linear-sequential life cycle model. It is very simple to understand and use. In a waterfall model, each phase must be completed before the next phase can begin and there is no overlapping in the phases.
The Waterfall model is the earliest SDLC approach that was used for software development. The waterfall Model illustrates the software development process in a linear sequential flow. This means that any phase in the development process begins only if the previous phase is complete.
In this waterfall model, the phases do not overlap.Why we choose waterfall modelAs we are clear about the application which we are developing. We know about the product which will come after the development.
We are clear about the technologies which we use in the development of this application. The functional requirement of the application is clear and there is no ambiguity in it. The application is short no complexity is found in the development of the application. Very less customer interaction is involved in the development of the product. Once the product is ready then only it can be demoted to the end users. Once the product is developed and if any failure occurs then the cost of fixing such issues are very high because we need to update everywhere from document till the logic.A general overview of the waterfallBalanced evaluationComparing MethodologiesWeaknesses StrengthsXPRequires on-site customerDocumentation primarily through verbal communication and code. For some teams these are the only artifacts created, others create a minimal design and user documentation.
Difficult for new adopters to determine how to accommodate architectural and design concerns. Strong technical practice.Customer ownership of feature priority, developer ownership of estimates.Frequent feedback opportunities.Most widely known and adopted approach, at least in the US.
Scrum Only provide project management support, other disciplines are out of scope.Does not specify technical practices.Can take some time to get the business to provide unique priorities for each requirement. Complements existing practice.Self-organizing teams and feedback.Customer participation and steering.Priorities based on business value.
The only approach here that has a certification process.LeanDoes not specify technical practices.Requires constant gathering of metrics which may be difficult for some environments to accommodate.Theory of constraints can be a complex and difficult aspect to adopt.
Complements existing practices.Focuses on project ROI.Eliminates all project waste.Cross-functional teams.FDDPromotes individual code ownership as opposed to shared/team ownership.Iterations are not as well defined by the process as other agile methodologies.
The model-centric aspects can have huge impacts when working on an existing system that has no models. Supports multiple teams working in parallel.All aspects of the project tracked by feature.Design by feature and build by feature aspects are easy to understand and adapt.
Scales to large teams or projects well.AUPHigher levels of the ceremony may be a hindrance in smaller projects.Minimal attention to team dynamics.Documentation is much more formal than most approaches mentioned here. The robust methodology with many artifacts and disciplines to choose from.Scales up very well.
Documentation helps to communicate in distributed environments.Priorities set based on highest risk. Risk can be a business or technical risk.
CrystalExpects all team member to be co-located. May not work well for distributed teams.Adjustments are required from one project size/structure to another in order to follow the prescribed flavor of Crystal for that project size/criticality.Moving from one flavor of Crystal to another in mid-project doesn’t work, as the crystal was not designed to be upward or downward compatible. The family of methodologies designed to scale by project size and criticality.Only methodology that specifically accounts for life-critical projects.
As project size grows, cross-functional teams are utilized to ensure consistency.The “human” component has been considered for every aspect of the project support structure. DSDMProbably the most heavyweight project compared in this survey.Expects continuous user involvement.Defines several artifacts and work products for each phase of the project; heavier documentation.
Access to material is controlled by a consortium, and fees may be charged just to access the reference material An emphasis on testing is so strong that at least one tester is expected to be on each project team.Designed from the ground up by business people, so the business value is identified and expected to be the highest priority deliverable.Has specific approach to determining how important each requirement is to an iteration.
Sets stakeholder expectations from the start of the project that not all requirements will make it into the final deliverable.ReferencesBarry, C., Conboy, K., Lang, M., Wojtkowski, G., Wojtkowski, W.
(Eds.), Information Systems Development. Challenges in Practice, Theory, and Education Volume 1Burch, JG. Information systems: Theory and PracticeClydeBankBusiness. Agile Project Management and Scrum Feng, X., Liu, K.
and Jiang, G., eds. (2009) Information Systems in the changing era: theory and practice. Aussino Academic Publishing House, Sydney, Australia, pp549. ISBN 9780980605723 (Proceedings of the 11th International Conference on Informatics and Semiotics in Organizations) Rainer, R. K., & Cegielski, C.
G. (2013). Introduction to Information Systems, 4th Edition, International Student Version, Wiley.Sims, C. & Johnson, HL (2012). Scrum: A breathtakingly brief and agile introduction.
DymaxiconValacich, J., & Schneider, C. (2013). Information Systems Today: Managing in the Digital World, 6th Edition, Pearson Education.Wilson, Matthew W. 2011.
“Data matter(s): legitimacy, coding, and qualifications-of-life.” Environment and Planning D: Society and Space no. 29 (5):857-872.
