Upgrade to remove ads
IS BOOK Ch. 11 Review Questions
Terms in this set (12)
11-1) What are the seven phases of the systems development life cycle? What activities occur in each phase?
This is the first phase in the systems development process. It identifies whether or not there is the need for a new system to achieve a businesses' strategic objectives. This is a preliminary plan (or a feasibility study) for a company's business initiative to acquire the resources to build on an infrastructure to modify or improve a service.
Systems Analysis and Requirements: The second phase is where businesses will work on the source of their problem or the need for a change. Functional requirements of a system are considered here. It is also where system analysis takes place - or analyzing the needs of the end users to ensure the new system can meet their expectations.
Systems Design: The third phase describes, in detail, the necessary specifications, features and operations that will satisfy the functional requirements of the proposed system which will be in place. This is the step for end users to discuss and determine their specific business information needs for the proposed system. It's during this phase that they will consider the essential components (hardware and/or software) structure (networking capabilities), processing and procedures for the system to accomplish its objectives.
Development: The fourth phase is where the IT/IS project will be built and programmed. System designers normally assume responsibility of this role. They prepare the new system.
Integration and Testing: The fifth phase involves systems integration and system testing (of programs and procedures) - normally carried out by a Quality Assurance (QA) professional - to determine if the proposed design meets the set of business goals planned in the first phase. Testing may be repeated - to check for errors, bugs and interoperability - until the end user finds it acceptable.
Implementation: The sixth phase involves installment of the newly-developed system. This step puts the project into production. Both system analysts and end-users should now see the realization of the project that has implemented changes.
Operations and Maintenance: The seventh and final phase is maintenance and future changes, if required. This is the step where end users can fine-tune the system, if they wish, to boost performance, add new capabilities to the system or have additional user requirements.
11-2) What is the waterfall method of software development? How do the SDLC tasks occur in this method of development? What are the success rates for systems developed using the waterfall method? Is the waterfall method dead? Why does the waterfall methodology persist despite its track record?
The waterfall model is a sequential (non-iterative) design process, used in software development processes, in which progress is seen as flowing steadily downwards (like a waterfall) through the phases of conception, initiation, analysis, design, construction, testing, production/implementation and maintenance.
The system development life cycle framework provides a sequence of activities for system designers and developers to follow. It consists of a set of steps or phases in which each phase of the SDLC uses the results of the previous one.
The SDLC adheres to important phases that are essential for developers, such as planning, analysis, design, and implementation, and are explained in the section below. It includes evaluation of present system, information gathering, feasibility study and request approval. A number of SDLC models have been created: waterfall, fountain, spiral, build and fix, rapid prototyping, incremental, synchronize and stabilize. The oldest of these, and the best known, is the waterfall model: a sequence of stages in which the output of each stage becomes the input for the next. These stages can be characterized and divided up in different ways, including the following: Preliminary analysis, Systems analysis, requirements definition, Systems design: Describes desired features and operations in detail, including screen layouts, business rules, process diagrams, pseudocode and other documentation.
Development: The real code is written here.
Integration and testing: Brings all the pieces together into a special testing environment, then checks for errors, bugs and interoperability.
Acceptance, installation, deployment: The final stage of initial development, where the software is put into production and runs actual business.
Maintenance: During the maintenance stage of the SDLC, the system is assessed to ensure it does not become obsolete. This is also where changes are made to initial software. It involves continuous evaluation of the system in terms of its performance.
Evaluation: Some companies do not view this as an official stage of the SDLC, while others consider it to be an extension of the maintenance stage, and may be referred to in some circles as post-implementation review.
The results of this "inspect-and-adapt" approach to development greatly reduce both development costs and time to market. Because teams can develop software at the same time they're gathering requirements, the phenomenon known as "analysis paralysis" is less likely to impede a team from making progress. And because a team's work cycle is limited to two weeks, it gives stakeholders recurring opportunities to calibrate releases for success in the real world.
terative development is a way of breaking down the software development of a large application into smaller chunks. In iterative development, feature code is designed, developed and tested in repeated cycles. With each iteration, additional features can be designed, developed and tested until there is a fully functional software application ready to be deployed to customers.
This high level description is then further broken down into the components and modules which can be analyzed, designed, and constructed separately and integrated to accomplish the business goal. SDLC and SAD are cornerstones of full life cycle product and system planning.
"Agile Development" is an umbrella term for several iterative and incremental software development methodologies. The most popular agile methodologies include Extreme Programming (XP), Scrum, Crystal, Dynamic Systems Development Method (DSDM), Lean Development, and Feature-Driven Development (FDD).
The systems development life cycle (SDLC), also referred to as the application development life-cycle, is a term used in systems engineering, information systems and software engineering to describe a process for planning, creating, testing, and deploying an information system. The systems development life-cycle concept applies to a range of hardware and software configurations, as a system can be composed of hardware only, software only, or a combination of both.
The roles and organization structures described in this article are meant to be representative -- your approach may differ slightly because you are in a different situation. But, if you think that your approach needs to be significantly different then you likely haven't yet fully given up on the thinking behind traditional IT roles and are likely putting your agile adoption at risk as a result. Also, this article does not address enterprise-level roles.
Iterative and incremental development are essential parts of the Modified waterfall models, Rational Unified Process, Extreme Programming and generally the various agile software development frameworks.
It follows a similar process to the plan-do-check-act cycle of business process improvement.
Successful software development projects require having a great idea that you get to market quickly — ahead of your competition. This need for speed means reducing the amount of hand-coding done by your development team and increasing code re-use in a way that doesn't introduce risk or add errors to your final product.
To that end, understanding the software development lifecycle means that once you move beyond your initial idea, there are a whole lot of additional steps to complete before you reach the delivery of your end product. If you standardize your development environments and processes while working through each of the requisite phases — analysis, design, development, integration and testing, acceptance, deployment, and maintenance — you'll experience less disruption to your organization and get maximum buy-in from your target audience.
When comparing development methodologies, it's valuable to review the advantages they offer; though ultimately your choice will be an exercise in both education and instinct. While there is always the temptation to look for an itemized list of disadvantages, the downsides are difficult to generalize. If you want to know the best methodology — or methodologies — to choose, it's really best to focus on how the various options excel and apply them to specific situations.
Advantage: Custom software will generally produce the most efficient system as it is can provide support for the specific needs of the business, which might not be available in an off-the-shelf solution and will provide greater efficiency or better customer service.
Disadvantages: The main disadvantages of custom software are development time and cost. With a spreadsheet or an off-the-shelf software package, a user can get benefits quickly. With custom software, a business needs to go through a Software development process that may take weeks, months, or with bigger projects, years. Bugs accidentally introduced by software developers, and thorough testing to iron out bugs, may impede the process and cause it to take longer than expected. However, spreadsheets and off-the-shelf software packages may also contain bugs, and moreover because they may be deployed at a business without formal testing, these bugs may slip through and cause business-critical errors.
The level of customization is perhaps the biggest benefit of custom software. While a commercial package may fit many of your business's needs, it's doubtful that it will have the same efficiency as custom software. By meeting your exact specifications, you can cover every aspect of your business without unnecessary extras. It gives you greater control, which is important if your business has specific needs that your average commercial product can't fulfill. Having customized software should also make the interface more familiar and easy to use.
Your team of in-house developers may lack the knowledge and expertise to create sophisticated software capable of handling all the tasks you require. If you only need basic software, this probably won't be an issue. However, if you need more sophisticated software, this could be more trouble than it's worth and lead to bugs and glitches. This may force you to bring in outside consultants who lack familiarity with your business, which can also be detrimental.
Rule of Thumb: One Architect/Analyst can generate enough work for two Developers and one Tester, structure your project teams in this ratio.
Your Business Analysts are the face of your project to the widest number of business people. It is their job to gather and consolidate all the needs and desires of the business — the Requirements — within the project scope, in such a way that the business people can understand and approve the result ("Yes, that is what I will pay for."), and that designers/developers can build the system that will meet those needs ("Yes, I can build something that will do this.").
The six-step process I outline in this article should help you make the right decision on that next project.
Step 1: Validate the need for technology
Many organizations often choose an enabling technology before identifying any legitimate business need. Sometimes this "cart before the horse" approach is due to rigid business processes, lack of technical knowledge, or pure product hype, which commands many a tech guru's attention. Decision makers are very often awed by product suite success stories, dynamite product demonstrations, and industry analysts' evaluation of technology—even when they haven't formally identified a need for the technology.
Step 2: Identify core business requirements
In large organizations, pinpointing core business requirements is often easier said than done but is nonetheless critical before enabling a business solution. A core business requirement is one that must be supported by the solution to continue. If a requirement can be only partially met or not addressed by a solution, it is not a core requirement.
Step 3: Identify architectural requirements
Most organizations are already using technology to enable their business processes. To reduce the cost of operation and maintenance of this technology, these organizations have established standards to which all solutions must adhere.
Step 4: Examine existing solutions
At this point, a business need has been pinpointed, ROI has been estimated, and both core business and architectural restrictions have been identified. Leaders should now take a good look at existing systems.
Step 5: Do you have in-house skills to support a custom solution?
The major factor that significantly reduces the ROI of a custom solution (and in many cases, ultimately causes the endeavor to fail) is the lack of available personnel with proper skill sets. It takes many skills to design and deploy a business solution that is both scaleable and extensible. Unless one of your business areas is product development
Cross-functional teams often function as self-directed teams assigned to a specific task which calls for the input and expertise of numerous departments. Assigning a task to a team composed of multi-disciplinary individuals increases the level of creativity and out of the box thinking[clarify]. Each member offers an alternative perspective to the problem and potential solution to the task. In business today, innovation is a leading competitive advantage and cross-functional teams promote innovation through a creative collaboration process. Members of a cross-functional team must be well versed in multi-tasking as they are simultaneously responsible for their cross-functional team duties as well as their normal day-to-day work tasks.
Cross-functional teams combine people with different areas of expertise from separate departments such as finance, human resources, and marketing.
The range of knowledge on cross-functional teams creates a broader perspective that can lead to new ideas and better solutions and also avert risks and poor outcomes.
The diversity of cross-functional teams can create challenges to effective communication and collaboration.
Source: Boundless. "Cross-Functional Teams." Boundless Management. Boundless, 26 May. 2016. Retrieved 31 Aug. 2016 from https://www.boundless.com/management/textbooks/boundless-management-textbook/groups-teams-and-teamwork-6/types-of-teams-52/cross-functional-teams-263-1547/
Procurement today is a complex management service, intended to support the strategic aims of the organisation. However, some of Procurement's intended customers are confused about its role and intentions-and hence don't trust its motives. This is only partially due to customers' misunderstandings; a good bit of it is Procurement's own fault. Whilst presenting itself as a strategic business partner, some purchasing practices are in fact tactical-and worse yet, self-serving.
Impact - good or bad
Just like any other contractor, human resources consultants can have a significant impact on your company, so make sure you choose someone who invests time getting to know you and your organization so that the impact they do have is a positive one - one that's in line with your vision and goals.
Cost effective Efficiency Employee development Regaining primary focus Save time Employee satisfaction and decreased turnover Minimizing risk management Return on investment
The biggest disadvantage can be the morale of employees who hear that an "outsourced consultant" is being brought in. These loaded words brings connotations of job losses and pay cuts. Lower morale, can often lead to less productivity. (You may find employees asking why the business would spend money on consultants and not offer bonuses.)
Lack of in-house expertise
YOU MIGHT ALSO LIKE...
MIS Quiz #2
MSIS CH. 9
13: Systems Development
Ch. 12 MC
OTHER SETS BY THIS CREATOR
Ch. 5 key terms
IS BOOK Ch. 10 Review Questions
IS BOOK Ch. 8 Review Questions
IS BOOK Ch. 6 Review Questions