IFSM 301 – Week 4 Citations
(NIST, 2009)
(The six phases of project management, n.d.)
(Waterfall versus Agile Project Management, n.d.)
(Gottesdiener, 2008)
(Value Attainment)
(Potts, 2008)
(Potts, Why You Shouldn't Have an IT Budget, 2008)
(UMUC Faculty)
Bibliography
Gottesdiener, E. (2008, March). Good Practices for Developing User Requirements. The Journal
of Defense Software Engineering, 13-17. Retrieved January 25, 2021, from
https://learn.umgc.edu/d2l/le/content/541520/viewContent/20543074/View
NIST. (2009, April). The System Development Life Cycle. Retrieved January 25, 2021, from
NIST: https://learn.umgc.edu/d2l/le/content/541520/viewContent/20543036/View
Potts, C. (2008, November 15). It's Time to Change Your Investment Culture. CIO, 24-26.
Retrieved January 25, 2021, from
https://learn.umgc.edu/d2l/le/content/541520/viewContent/20543105/View
Potts, C. (2008, May 15). Why You Shouldn't Have an IT Budget. CIO, 74-76. Retrieved
January 25, 2021, from
https://learn.umgc.edu/d2l/le/content/541520/viewContent/20543106/View
The six phases of project management. (n.d.). Retrieved January 25, 2021, from University of
Maryland Global Campus:
https://learn.umgc.edu/d2l/le/content/541520/viewContent/20543072/View
UMUC Faculty. (n.d.). Performance Measures. Retrieved January 25, 2021, from University of
Maryland Global Campus:
https://learn.umgc.edu/d2l/le/content/541520/viewContent/20543077/View
Value Attainment. (n.d.). Retrieved January 25, 2021, from University of Maryland Global
Campus: https://learn.umgc.edu/d2l/le/content/541520/viewContent/20543075/View
Waterfall versus Agile Project Management. (n.d.). Retrieved January 25, 2021, from University
of Maryland Global Campus:
https://learn.umgc.edu/d2l/le/content/541520/viewContent/20543073/View
The System Development Life Cycle
For a brief overview of the System Development Life Cycle, the following sections have been directly
quoted from the National Institute of Standards and Technology (NIST) publication, The System
Development Life Cycle (SDLC). The entire NIST publication is available at:
http://csrc.nist.gov/publications/nistbul/april2009_system-development-life-cycle.pdf
"The system development life cycle is the overall process of developing, implementing, and retiring
information systems through a multistep process from initiation, analysis, design, implementation, and
maintenance to disposal. There are many different SDLC models and methodologies, but each generally
consists of a series of defined steps or phases.
The System Development Life Cycle
Initiation Phase. During the initiation phase, the organization establishes the need for a system and
documents its purpose.
Development/Acquisition Phase. During this phase, the system is designed, purchased, programmed,
developed, or otherwise constructed. should be identified as well.
Implementation Phase. In the implementation phase, the organization conf ...
The document discusses systems analysis and design (SAD), which refers to the process of examining a business situation with the intent of improving it through better procedures and methods. SAD involves defining problems, requirements, and specifications, as well as designing solutions and implementations. It discusses the various phases of system development like planning, analysis, design, development, testing, implementation, and maintenance. It also describes different approaches to system development like process-oriented, object-oriented, and data-oriented. Finally, it discusses different system development life cycle (SDLC) models like waterfall, spiral, and agile models.
Information System Acquisition & Lifecycle: system acquisition process, phases: Initiation, Planning, Procurement, System Development, System Implementation, Maintenance & Operations, and Closeout. development models.
Archibald di filippo_comprehensive_plc_model_finalsansharmajs
This document discusses comprehensive project life cycle models that include additional phases beyond the typical starting, organizing, executing, and closing phases. It proposes that projects should be viewed as having an incubation/feasibility phase before starting and a post-project evaluation phase after closing. The document asserts that recognizing these additional phases allows for a more holistic systems perspective when managing projects. It also discusses the importance of tailoring life cycle models to specific project categories and providing detailed definitions of phases and decision points within each model. Adopting comprehensive, category-specific models can help organizations better plan, execute, and evaluate their projects.
Project on multiplex ticket bookingn system globsyn2014Md Imran
This document appears to be a project report for a movie ticket booking system developed using ASP.Net. It includes sections like acknowledgements, objectives, feasibility analysis, system requirements, database design, tables used, data flow diagrams, screenshots of the system, code snippets and references. The system allows users to book movie tickets, and has functionality for admins to add movies, theaters and manage the system. Group members who worked on the project are also listed.
The document discusses the system development life cycle (SDLC) approach for developing an information security policy for an integrated information system (IIS) and its data. It will apply the SDLC process, including planning and analysis, design, implementation, and testing phases. The goal is to address privacy and confidentiality threats specified in a case study by developing an information security policy for the IIS.
SDLC Apresentação - Shift Education of TechnologyRaphaff
The document discusses the software development lifecycle (SDLC) process. It describes the traditional five phases of the SDLC and how it has evolved to seven phases. Each phase is explained in detail, including planning, analysis, design, development, integration and testing, implementation, and operations and maintenance. Different SDLC models like waterfall, iterative, and agile are also summarized. The agile manifesto and scrum framework are introduced as part of the agile methodology. Key terms related to SDLC documentation are defined in a glossary.
19701759 Project Report On Railway Reservation System By Amit MittalCourtney Esco
This document provides an overview of a term paper on object oriented programming for a railway reservation system course. It includes sections on the proposed system, system development life cycle, source code, testing, data flow diagram, advantages, and requirements. The system development life cycle section describes the initiation, planning, requirements analysis, design, development, testing, implementation, and maintenance phases of the project.
This document discusses several software development models and practices. It describes the waterfall model which involves sequential stages of requirement analysis, design, implementation, testing, and maintenance. It also covers prototyping, rapid application development (RAD), and component assembly models which are more iterative in nature. The prototyping model involves creating prototypes to help define requirements, RAD emphasizes reuse and short development cycles, and component assembly focuses on reusing existing software components.
The document discusses systems analysis and design (SAD), which refers to the process of examining a business situation with the intent of improving it through better procedures and methods. SAD involves defining problems, requirements, and specifications, as well as designing solutions and implementations. It discusses the various phases of system development like planning, analysis, design, development, testing, implementation, and maintenance. It also describes different approaches to system development like process-oriented, object-oriented, and data-oriented. Finally, it discusses different system development life cycle (SDLC) models like waterfall, spiral, and agile models.
Information System Acquisition & Lifecycle: system acquisition process, phases: Initiation, Planning, Procurement, System Development, System Implementation, Maintenance & Operations, and Closeout. development models.
Archibald di filippo_comprehensive_plc_model_finalsansharmajs
This document discusses comprehensive project life cycle models that include additional phases beyond the typical starting, organizing, executing, and closing phases. It proposes that projects should be viewed as having an incubation/feasibility phase before starting and a post-project evaluation phase after closing. The document asserts that recognizing these additional phases allows for a more holistic systems perspective when managing projects. It also discusses the importance of tailoring life cycle models to specific project categories and providing detailed definitions of phases and decision points within each model. Adopting comprehensive, category-specific models can help organizations better plan, execute, and evaluate their projects.
Project on multiplex ticket bookingn system globsyn2014Md Imran
This document appears to be a project report for a movie ticket booking system developed using ASP.Net. It includes sections like acknowledgements, objectives, feasibility analysis, system requirements, database design, tables used, data flow diagrams, screenshots of the system, code snippets and references. The system allows users to book movie tickets, and has functionality for admins to add movies, theaters and manage the system. Group members who worked on the project are also listed.
The document discusses the system development life cycle (SDLC) approach for developing an information security policy for an integrated information system (IIS) and its data. It will apply the SDLC process, including planning and analysis, design, implementation, and testing phases. The goal is to address privacy and confidentiality threats specified in a case study by developing an information security policy for the IIS.
SDLC Apresentação - Shift Education of TechnologyRaphaff
The document discusses the software development lifecycle (SDLC) process. It describes the traditional five phases of the SDLC and how it has evolved to seven phases. Each phase is explained in detail, including planning, analysis, design, development, integration and testing, implementation, and operations and maintenance. Different SDLC models like waterfall, iterative, and agile are also summarized. The agile manifesto and scrum framework are introduced as part of the agile methodology. Key terms related to SDLC documentation are defined in a glossary.
19701759 Project Report On Railway Reservation System By Amit MittalCourtney Esco
This document provides an overview of a term paper on object oriented programming for a railway reservation system course. It includes sections on the proposed system, system development life cycle, source code, testing, data flow diagram, advantages, and requirements. The system development life cycle section describes the initiation, planning, requirements analysis, design, development, testing, implementation, and maintenance phases of the project.
This document discusses several software development models and practices. It describes the waterfall model which involves sequential stages of requirement analysis, design, implementation, testing, and maintenance. It also covers prototyping, rapid application development (RAD), and component assembly models which are more iterative in nature. The prototyping model involves creating prototypes to help define requirements, RAD emphasizes reuse and short development cycles, and component assembly focuses on reusing existing software components.
Management Information Systems – Week 7 Lecture 2Developme.docxcroysierkathey
Management Information Systems – Week 7 Lecture 2
Development & Improvement
Chapter 13 Systems Development: Design, Implementation, Maintenance,
and Review
You have learned about information systems and seen a little about how the project is run to create a new
system. This week you will focus on the actual systems design process. This will help you whether you
become a programmer, systems analyst or are a department manager. There are countless articles on
this subject on the internet and some great YouTube videos so take a moment to do some extra research
and learn more about systems development.
When an IS manager sits down to design a system they look at several areas and have many special
tools at their disposal.
A systems engineer or senior developer will first look at the logical design. This usually means that they
look at the user request and determine what they really mean! Once they have clarification they will create
a physical design. This might be object-oriented (using code that has already been created) or mock ups
showing interface design and controls. This is sometimes called storyboarding. This image is an example
of creating a new user interface:
System design time is an investment for the business, it will help by preventing, detecting, and correcting
errors prior to the application software being written. It will generate systems design alternatives. One
alternative is to ask software developers to create the application for the business, this is done by creating
a request for proposal (RFP). Software vendors will then propose several options at various price points.
The business can then review the proposals, do a cost benefit analysis and select an appropriate plan of
action.
Once a project has started it is a good idea to freezing design specifications using a contract, and even a
design report called a Functional Design Document. This process is intended to allow the development
team to focus on creating a specific application and not have to try to hit a constantly moving target. As
the application is being developed it is also time to acquire the hardware that will be needed. If the
application requires a headset with microphone for voice input or a super-fast computer, this is the time to
make sure the application will be functional when it is implemented.
Types of IS hardware vendors include:
General computer manufacturers
Small computer manufacturers
Peripheral equipment manufacturers
Computer dealers and distributors
Chip makers
While the application is being developed and the hardware acquired, in a perfect world the personnel will
be hired and trained and any preparations will be done for the site and data requirements (additional disk
drives for databases or could computing). One of the phases of software development is the testing
phase. It really cannot be considered the final stage because it may result in some additional planning,
programming or other modifications. It can be considered to be ...
Social Media Site User Management System Class 12th Informatics Practices Pyt...deboshreechatterjee2
This document is a project report submitted by a student named Debshri Chatterjee for their class XII subject Informatics Practices. The report details the development of a social media site user management system using various data analysis, visualization, and manipulation techniques in Python. The system was developed using the system development life cycle methodology, which includes phases for initiation, planning, analysis, design, development, testing, implementation, and maintenance. The report includes the source code implementing functions for reading, sorting, plotting, and manipulating the user data.
Cosmetic shop management system project report.pdfKamal Acharya
Buying new cosmetic products is difficult. It can even be scary for those who have sensitive skin and are prone to skin trouble. The information needed to alleviate this problem is on the back of each product, but it's thought to interpret those ingredient lists unless you have a background in chemistry.
Instead of buying and hoping for the best, we can use data science to help us predict which products may be good fits for us. It includes various function programs to do the above mentioned tasks.
Data file handling has been effectively used in the program.
The automated cosmetic shop management system should deal with the automation of general workflow and administration process of the shop. The main processes of the system focus on customer's request where the system is able to search the most appropriate products and deliver it to the customers. It should help the employees to quickly identify the list of cosmetic product that have reached the minimum quantity and also keep a track of expired date for each cosmetic product. It should help the employees to find the rack number in which the product is placed.It is also Faster and more efficient way.
The document discusses the system development life cycle (SDLC), which includes various phases for developing and maintaining systems. The key phases are: system investigation, feasibility study, system analysis, system design, coding, testing, implementation, and maintenance. The feasibility study phase evaluates the technical, operational, economic, motivational, and schedule feasibility of a proposed system. The system analysis phase involves studying user requirements and the current system. System design then specifies how the new system will meet requirements through elements like data design, user interface design, and process design. This produces specifications for the system.
Asset finance system project initiation 101. “Selecting and implementing a new asset finance system? In the second of three articles, we go back to basics to take a look at what you need to consider at the start of your project to give yourself the best chance of success.” This has necessarily been a brief look at Project Initiation. We welcome comments and would be happy to help you get your project off to a good start.
Overview Of System Development Life Cycle (SDLC)Nicole Savoie
The document discusses the system development life cycle (SDLC), which is a process used for developing systems from planning through implementation. It contains four main steps: analysis, planning, design, and implementation. During analysis, data flow diagrams are used to model the system's processes. Consistency between context and lower-level data flow diagrams is important for an easy-to-follow process model. SDLC is also used to determine how an information system can support business needs by designing, building, and delivering the system to users through the analysis, design, implementation, and testing phases. Procedure models created during analysis help define requirements graphically. Reliability of the process model is key to improving later SDLC stages.
Management of time uncertainty in agileijseajournal
Agile software development represents a major departure from traditional methods of software
engineering. It had huge impact on how software is developed worldwide. Agile software development
solutions are targeted at enhancing work at project level. But it may encounter some uncertainties in its
working. One of the key measures of the resilience of a project is its ability to reach completion, on time
and on budget, regardless of the turbulent and uncertain environment it may operate within. Uncertainty of
time is the problem which can lead to other uncertainties too. In uncertainty of time the main issue is that
the how much delay will be caused by the uncertain environment and if the project manager comes to know
about this delay before, then he can ask for that extra time from customer. So this paper tries to know about
that extra time and calculate it.
The document discusses the Software Development Life Cycle (SDLC), outlining its main phases: planning, requirements analysis, feasibility study, system design, development/coding, system testing, implementation, and maintenance. It provides details on each phase, explaining their key activities and purposes. The SDLC is presented as a process used by systems analysts to develop information systems according to requirements, while ensuring quality, on-time and on-budget completion, effective performance, and cost-efficient maintenance.
This document is a project report for a Gas Inventory Management System created by four students at Jawahar Navodaya Vidyalaya Rajgarh in Madhya Pradesh, India. It includes an introduction to the project, objectives, proposed system description, phases of the system development life cycle used (initiation, concept development, requirements analysis, design, development, integration and testing, implementation, and operations/maintenance). It also includes sections on flowchart, source code, outputs, and hardware/software requirements. The project was created for a Computer Science class and guided by their teacher, Mr. Anil Kant.
“Selecting and implementing a new asset finance system? In the second of three articles, we go back to basics to take a look at what you need to consider at the start of your project to give yourself the best chance of success.”
This has necessarily been a brief look at Project Initiation. We welcome comments and would be happy to help you get your project off to a good start.
The document provides an overview of a student information management system. It discusses how the system will maintain student records online and make it easier for schools and colleges to manage student data and activities. The system will store all student details and allow for easy searching of student records. It will also enable online registration and updating of student profiles. The document outlines the objectives, scope, requirements analysis, and design of the student information management system.
The document provides an overview of a student information management system. It discusses how the system will maintain student records online and make it easier for schools and colleges to manage student data and activities. The system will store all student details and allow for easy searching of student records. It will also enable online registration and updating of student profiles. The document outlines the objectives, scope, requirements analysis, and design of the student information management system.
This document contains George Chang's responses to frequently asked questions about billings and project milestones for IT projects. Chang explains that they use a waterfall approach with initial planning, analysis, design, implementation, and maintenance phases. This structured approach aims to eliminate uncertainty upfront. Agile methods are best for some uncertainty, but not for projects with 80% certainty. A project plan, business case, and system specifications document are produced at each phase to define requirements and manage the project. Project management is important to meet goals for schedule, budget, quality and risk management.
· Choose an information system for an individual project. During .docxLynellBull52
· Choose an information system for an individual project. During the course your project will be developing a hypothetical system. Each week you will develop parts of the plan. Weekly assignments include a system description, needs analysis, feasibility analysis, data analysis, process analysis, and financial analysis. The final assignment will be to consolidate all previous assignments into one document.
· The role of the facilitator will be to function as the business leader or stake holder who will use the proposed system for competitive advantage. Each student will interview the facilitator as well as the balance of the class duringproject description and needs analysisphase.
· Write and submit a detailed description of the information system chosen for the Information Systems Plan. Include the system name, type of system, key system benefits, along with interrelations and interdependencies with other systems. If there is an existing system to be replaced or upgraded, provide a description of the replacement or upgrade and the associated supporting technology.
·
1
1. Project Initiation Phase
Validation Master Plan (VP)
2. Requirement Phase
Traceability Matrix
3. Analysis Phase Phaseition Phase
Traceability Matrix
(update solution column)
5. Development Phase and Testing
6. Implementation Phase
Planned
Site SOPs
Technology Architecture
Project Definition
PPQ
Traceability Matrix
(update test column)
System Design Specification (SDS)
4. Design Phase
Technical System Design
Validation Report (VR)
Traceability Matrix
(update solution column)
Test Plan (TP)
Updated or created
IT SOPs
System and software IQ’s
(Production)
Testing
System/OQ, Integration, User
Acceptance Test cases (TC)
(pre-approved and executed)
Post Live
Deliverable archiving
Change Control procedure
User and System
manuals, training, guidelines
System Retirement Strategy
Transition Plan
System and software IQ’s
Test Report (TR)
Requirements
(System and Functional)
Site Q review of each deliverable will occur as a consequence of project milestones.
Delivered
2
Validation Packet How is it done?
Each packet is organized based on the uniqueness of the project. The basic deliverables really don’t change that much. Remember – Validation packet is based on a proven model based on an evolving IO/IA viewpoint years of expertise has gone into this. . .
The basic 6-phase SDLC approach is the structure. Makes little difference if SDLC or something else is the structure – project methodologies are basically the same . . .
E-room and/or any team-accessed file structure solution is the working repository of documentation activity – that occur as a function of milestone project. A key element of validation packet is the fact that quality review is an active function - “Green Light”.
Project team members are assigned key deliverables and off we go . . .
The tracking of deliverables becomes a self-fulfilling prophecy of validated d.
The document summarizes and compares two software development methods: Dynamic Systems Development Method (DSDM) and Rapid Application Development (RAD). It provides an overview of the characteristics and principles of DSDM, including that it is more suitable for in-house and market-driven projects rather than contract-driven projects. The major weakness is that requirements are loosely defined and it is difficult to plan. However, the major strength is that the end products fit business needs well since users are heavily involved. It also briefly summarizes RAD and identifies some similarities and differences between the two methods.
The document describes the six phases of the systems development life cycle: 1) preliminary investigation, 2) systems analysis, 3) systems design, 4) systems development, 5) systems implementation, and 6) systems maintenance. Each phase involves specific activities like gathering requirements, designing system components, developing and acquiring software/hardware, testing, training users, and ongoing maintenance. Traceability matrices are used to map requirements to designs and validate that the life cycle process is followed.
Here are the DFD diagrams for the Online Auction System:
Level 0 (Context Level) DFD:
Online Auction System (Context Diagram)
Seller - Post Product Details
Buyer - View Auction Updates, Search Products, View Products
Level 1 DFD:
Online Auction System
Seller
- Post Product
- Product Details
Buyer
- Search Products
- View Products Details
Administrator
- Manage Products
- Manage Users
Database
- Product Details
- User Details
This shows the basic data flows in and out of the overall Online Auction System at a high level (Level 0) and then breaks it down further
Integrated Analysis of Traditional Requirements Engineering Process with Agil...zillesubhan
In the past few years, agile software development approach has emerged as a most attractive software development approach. A typical CASE environment consists of a number of CASE tools operating on a common hardware and software platform and note that there are a number of different classes of users of a CASE environment. In fact, some users such as software developers and managers wish to make use of CASE tools to support them in developing application systems and monitoring the progress of a project. This development approach has quickly caught the attention of a large number of software development firms. However, this approach particularly pays attention to development side of software development project while neglects critical aspects of requirements engineering process. In fact, there is no standard requirement engineering process in this approach and requirements engineering activities vary from situation to situation. As a result, there emerge a large number of problems which can lead the software development projects to failure. One of major drawbacks of agile approach is that it is suitable for small size projects with limited team size. Hence, it cannot be adopted for large size projects. We claim that this approach can be used for large size projects if traditional requirements engineering approach is combined with agile manifesto. In fact, the combination of traditional requirements engineering process and agile manifesto can also help resolve a large number of problems exist in agile development methodologies. As in software development the most important thing is to know the clear customer’s requirements and also through modeling (data modeling, functional modeling, behavior modeling). Using UML we are able to build efficient system starting from scratch towards the desired goal. Through UML we start from abstract model and develop the required system through going in details with different UML diagrams. Each UML diagram serves different goal towards implementing a whole project.
Find a recent merger or acquisition that has been announced in the.docxMalikPinckney86
Find a recent merger or acquisition that has been announced in the media. What are the implications for the merger or acquisition and plans for implementing the blending firms? Also, evaluate and describe two possible technological innovations that may have led to the merger or acquisition. Would you have obtained this new technology or innovation differently? Why? Include the reference information of the article. Respond substantively to at least two other learners.
.
Find an example of a document that misuses graphics. This can be a d.docxMalikPinckney86
Find an example of a document that misuses graphics. This can be a document that you have received (please blot out any sensitive information and names) or a document that you find on the Internet. Discuss how the graphics are misused and what could be done to better them. Address the three “Cs” of technical writing: Clarity, Conciseness, and Correctness. Add one or two personal experiences with this topic.
.
More Related Content
Similar to IFSM 301 – Week 4 Citations (NIST, 2009) (The six phas
Management Information Systems – Week 7 Lecture 2Developme.docxcroysierkathey
Management Information Systems – Week 7 Lecture 2
Development & Improvement
Chapter 13 Systems Development: Design, Implementation, Maintenance,
and Review
You have learned about information systems and seen a little about how the project is run to create a new
system. This week you will focus on the actual systems design process. This will help you whether you
become a programmer, systems analyst or are a department manager. There are countless articles on
this subject on the internet and some great YouTube videos so take a moment to do some extra research
and learn more about systems development.
When an IS manager sits down to design a system they look at several areas and have many special
tools at their disposal.
A systems engineer or senior developer will first look at the logical design. This usually means that they
look at the user request and determine what they really mean! Once they have clarification they will create
a physical design. This might be object-oriented (using code that has already been created) or mock ups
showing interface design and controls. This is sometimes called storyboarding. This image is an example
of creating a new user interface:
System design time is an investment for the business, it will help by preventing, detecting, and correcting
errors prior to the application software being written. It will generate systems design alternatives. One
alternative is to ask software developers to create the application for the business, this is done by creating
a request for proposal (RFP). Software vendors will then propose several options at various price points.
The business can then review the proposals, do a cost benefit analysis and select an appropriate plan of
action.
Once a project has started it is a good idea to freezing design specifications using a contract, and even a
design report called a Functional Design Document. This process is intended to allow the development
team to focus on creating a specific application and not have to try to hit a constantly moving target. As
the application is being developed it is also time to acquire the hardware that will be needed. If the
application requires a headset with microphone for voice input or a super-fast computer, this is the time to
make sure the application will be functional when it is implemented.
Types of IS hardware vendors include:
General computer manufacturers
Small computer manufacturers
Peripheral equipment manufacturers
Computer dealers and distributors
Chip makers
While the application is being developed and the hardware acquired, in a perfect world the personnel will
be hired and trained and any preparations will be done for the site and data requirements (additional disk
drives for databases or could computing). One of the phases of software development is the testing
phase. It really cannot be considered the final stage because it may result in some additional planning,
programming or other modifications. It can be considered to be ...
Social Media Site User Management System Class 12th Informatics Practices Pyt...deboshreechatterjee2
This document is a project report submitted by a student named Debshri Chatterjee for their class XII subject Informatics Practices. The report details the development of a social media site user management system using various data analysis, visualization, and manipulation techniques in Python. The system was developed using the system development life cycle methodology, which includes phases for initiation, planning, analysis, design, development, testing, implementation, and maintenance. The report includes the source code implementing functions for reading, sorting, plotting, and manipulating the user data.
Cosmetic shop management system project report.pdfKamal Acharya
Buying new cosmetic products is difficult. It can even be scary for those who have sensitive skin and are prone to skin trouble. The information needed to alleviate this problem is on the back of each product, but it's thought to interpret those ingredient lists unless you have a background in chemistry.
Instead of buying and hoping for the best, we can use data science to help us predict which products may be good fits for us. It includes various function programs to do the above mentioned tasks.
Data file handling has been effectively used in the program.
The automated cosmetic shop management system should deal with the automation of general workflow and administration process of the shop. The main processes of the system focus on customer's request where the system is able to search the most appropriate products and deliver it to the customers. It should help the employees to quickly identify the list of cosmetic product that have reached the minimum quantity and also keep a track of expired date for each cosmetic product. It should help the employees to find the rack number in which the product is placed.It is also Faster and more efficient way.
The document discusses the system development life cycle (SDLC), which includes various phases for developing and maintaining systems. The key phases are: system investigation, feasibility study, system analysis, system design, coding, testing, implementation, and maintenance. The feasibility study phase evaluates the technical, operational, economic, motivational, and schedule feasibility of a proposed system. The system analysis phase involves studying user requirements and the current system. System design then specifies how the new system will meet requirements through elements like data design, user interface design, and process design. This produces specifications for the system.
Asset finance system project initiation 101. “Selecting and implementing a new asset finance system? In the second of three articles, we go back to basics to take a look at what you need to consider at the start of your project to give yourself the best chance of success.” This has necessarily been a brief look at Project Initiation. We welcome comments and would be happy to help you get your project off to a good start.
Overview Of System Development Life Cycle (SDLC)Nicole Savoie
The document discusses the system development life cycle (SDLC), which is a process used for developing systems from planning through implementation. It contains four main steps: analysis, planning, design, and implementation. During analysis, data flow diagrams are used to model the system's processes. Consistency between context and lower-level data flow diagrams is important for an easy-to-follow process model. SDLC is also used to determine how an information system can support business needs by designing, building, and delivering the system to users through the analysis, design, implementation, and testing phases. Procedure models created during analysis help define requirements graphically. Reliability of the process model is key to improving later SDLC stages.
Management of time uncertainty in agileijseajournal
Agile software development represents a major departure from traditional methods of software
engineering. It had huge impact on how software is developed worldwide. Agile software development
solutions are targeted at enhancing work at project level. But it may encounter some uncertainties in its
working. One of the key measures of the resilience of a project is its ability to reach completion, on time
and on budget, regardless of the turbulent and uncertain environment it may operate within. Uncertainty of
time is the problem which can lead to other uncertainties too. In uncertainty of time the main issue is that
the how much delay will be caused by the uncertain environment and if the project manager comes to know
about this delay before, then he can ask for that extra time from customer. So this paper tries to know about
that extra time and calculate it.
The document discusses the Software Development Life Cycle (SDLC), outlining its main phases: planning, requirements analysis, feasibility study, system design, development/coding, system testing, implementation, and maintenance. It provides details on each phase, explaining their key activities and purposes. The SDLC is presented as a process used by systems analysts to develop information systems according to requirements, while ensuring quality, on-time and on-budget completion, effective performance, and cost-efficient maintenance.
This document is a project report for a Gas Inventory Management System created by four students at Jawahar Navodaya Vidyalaya Rajgarh in Madhya Pradesh, India. It includes an introduction to the project, objectives, proposed system description, phases of the system development life cycle used (initiation, concept development, requirements analysis, design, development, integration and testing, implementation, and operations/maintenance). It also includes sections on flowchart, source code, outputs, and hardware/software requirements. The project was created for a Computer Science class and guided by their teacher, Mr. Anil Kant.
“Selecting and implementing a new asset finance system? In the second of three articles, we go back to basics to take a look at what you need to consider at the start of your project to give yourself the best chance of success.”
This has necessarily been a brief look at Project Initiation. We welcome comments and would be happy to help you get your project off to a good start.
The document provides an overview of a student information management system. It discusses how the system will maintain student records online and make it easier for schools and colleges to manage student data and activities. The system will store all student details and allow for easy searching of student records. It will also enable online registration and updating of student profiles. The document outlines the objectives, scope, requirements analysis, and design of the student information management system.
The document provides an overview of a student information management system. It discusses how the system will maintain student records online and make it easier for schools and colleges to manage student data and activities. The system will store all student details and allow for easy searching of student records. It will also enable online registration and updating of student profiles. The document outlines the objectives, scope, requirements analysis, and design of the student information management system.
This document contains George Chang's responses to frequently asked questions about billings and project milestones for IT projects. Chang explains that they use a waterfall approach with initial planning, analysis, design, implementation, and maintenance phases. This structured approach aims to eliminate uncertainty upfront. Agile methods are best for some uncertainty, but not for projects with 80% certainty. A project plan, business case, and system specifications document are produced at each phase to define requirements and manage the project. Project management is important to meet goals for schedule, budget, quality and risk management.
· Choose an information system for an individual project. During .docxLynellBull52
· Choose an information system for an individual project. During the course your project will be developing a hypothetical system. Each week you will develop parts of the plan. Weekly assignments include a system description, needs analysis, feasibility analysis, data analysis, process analysis, and financial analysis. The final assignment will be to consolidate all previous assignments into one document.
· The role of the facilitator will be to function as the business leader or stake holder who will use the proposed system for competitive advantage. Each student will interview the facilitator as well as the balance of the class duringproject description and needs analysisphase.
· Write and submit a detailed description of the information system chosen for the Information Systems Plan. Include the system name, type of system, key system benefits, along with interrelations and interdependencies with other systems. If there is an existing system to be replaced or upgraded, provide a description of the replacement or upgrade and the associated supporting technology.
·
1
1. Project Initiation Phase
Validation Master Plan (VP)
2. Requirement Phase
Traceability Matrix
3. Analysis Phase Phaseition Phase
Traceability Matrix
(update solution column)
5. Development Phase and Testing
6. Implementation Phase
Planned
Site SOPs
Technology Architecture
Project Definition
PPQ
Traceability Matrix
(update test column)
System Design Specification (SDS)
4. Design Phase
Technical System Design
Validation Report (VR)
Traceability Matrix
(update solution column)
Test Plan (TP)
Updated or created
IT SOPs
System and software IQ’s
(Production)
Testing
System/OQ, Integration, User
Acceptance Test cases (TC)
(pre-approved and executed)
Post Live
Deliverable archiving
Change Control procedure
User and System
manuals, training, guidelines
System Retirement Strategy
Transition Plan
System and software IQ’s
Test Report (TR)
Requirements
(System and Functional)
Site Q review of each deliverable will occur as a consequence of project milestones.
Delivered
2
Validation Packet How is it done?
Each packet is organized based on the uniqueness of the project. The basic deliverables really don’t change that much. Remember – Validation packet is based on a proven model based on an evolving IO/IA viewpoint years of expertise has gone into this. . .
The basic 6-phase SDLC approach is the structure. Makes little difference if SDLC or something else is the structure – project methodologies are basically the same . . .
E-room and/or any team-accessed file structure solution is the working repository of documentation activity – that occur as a function of milestone project. A key element of validation packet is the fact that quality review is an active function - “Green Light”.
Project team members are assigned key deliverables and off we go . . .
The tracking of deliverables becomes a self-fulfilling prophecy of validated d.
The document summarizes and compares two software development methods: Dynamic Systems Development Method (DSDM) and Rapid Application Development (RAD). It provides an overview of the characteristics and principles of DSDM, including that it is more suitable for in-house and market-driven projects rather than contract-driven projects. The major weakness is that requirements are loosely defined and it is difficult to plan. However, the major strength is that the end products fit business needs well since users are heavily involved. It also briefly summarizes RAD and identifies some similarities and differences between the two methods.
The document describes the six phases of the systems development life cycle: 1) preliminary investigation, 2) systems analysis, 3) systems design, 4) systems development, 5) systems implementation, and 6) systems maintenance. Each phase involves specific activities like gathering requirements, designing system components, developing and acquiring software/hardware, testing, training users, and ongoing maintenance. Traceability matrices are used to map requirements to designs and validate that the life cycle process is followed.
Here are the DFD diagrams for the Online Auction System:
Level 0 (Context Level) DFD:
Online Auction System (Context Diagram)
Seller - Post Product Details
Buyer - View Auction Updates, Search Products, View Products
Level 1 DFD:
Online Auction System
Seller
- Post Product
- Product Details
Buyer
- Search Products
- View Products Details
Administrator
- Manage Products
- Manage Users
Database
- Product Details
- User Details
This shows the basic data flows in and out of the overall Online Auction System at a high level (Level 0) and then breaks it down further
Integrated Analysis of Traditional Requirements Engineering Process with Agil...zillesubhan
In the past few years, agile software development approach has emerged as a most attractive software development approach. A typical CASE environment consists of a number of CASE tools operating on a common hardware and software platform and note that there are a number of different classes of users of a CASE environment. In fact, some users such as software developers and managers wish to make use of CASE tools to support them in developing application systems and monitoring the progress of a project. This development approach has quickly caught the attention of a large number of software development firms. However, this approach particularly pays attention to development side of software development project while neglects critical aspects of requirements engineering process. In fact, there is no standard requirement engineering process in this approach and requirements engineering activities vary from situation to situation. As a result, there emerge a large number of problems which can lead the software development projects to failure. One of major drawbacks of agile approach is that it is suitable for small size projects with limited team size. Hence, it cannot be adopted for large size projects. We claim that this approach can be used for large size projects if traditional requirements engineering approach is combined with agile manifesto. In fact, the combination of traditional requirements engineering process and agile manifesto can also help resolve a large number of problems exist in agile development methodologies. As in software development the most important thing is to know the clear customer’s requirements and also through modeling (data modeling, functional modeling, behavior modeling). Using UML we are able to build efficient system starting from scratch towards the desired goal. Through UML we start from abstract model and develop the required system through going in details with different UML diagrams. Each UML diagram serves different goal towards implementing a whole project.
Similar to IFSM 301 – Week 4 Citations (NIST, 2009) (The six phas (20)
Find a recent merger or acquisition that has been announced in the.docxMalikPinckney86
Find a recent merger or acquisition that has been announced in the media. What are the implications for the merger or acquisition and plans for implementing the blending firms? Also, evaluate and describe two possible technological innovations that may have led to the merger or acquisition. Would you have obtained this new technology or innovation differently? Why? Include the reference information of the article. Respond substantively to at least two other learners.
.
Find an example of a document that misuses graphics. This can be a d.docxMalikPinckney86
Find an example of a document that misuses graphics. This can be a document that you have received (please blot out any sensitive information and names) or a document that you find on the Internet. Discuss how the graphics are misused and what could be done to better them. Address the three “Cs” of technical writing: Clarity, Conciseness, and Correctness. Add one or two personal experiences with this topic.
.
Find a scholarly research study from the Ashford University Library .docxMalikPinckney86
Find a scholarly research study from the Ashford University Library that uses measurement scales for data collection (e.g., a survey). Explain the measurement scales that the study used, and evaluate them. Did you think the researchers made good decisions about the scales? Why or why not? Cite the study in your post, and document it in APA style as outlined in the Ashford Writing Center
.
Find a work of visual art, architecture, or literature from either A.docxMalikPinckney86
Find a work of visual art, architecture, or literature from either Ancient Greece or Rome that appeals to you. Ensure that your choice was created in the time frames identified here. It should not simply be a depiction of something in this time period.
In your initial post, describe where you can see the influence of your work of art in modern and contemporary times. What elements (its style, ideas, purpose, principles) can we see reflected in the world today, in art or in other areas, including government, philosophy, social structure, and entertainment?
.
Find a real-life” example of one of the following institutions. Exa.docxMalikPinckney86
Find a “real-life” example of one of the following institutions. Examples can be found in every state. A simple search for “Department of Corrections” is a good place to start.
Medium-Security Adult Male Institution
Regional Parole and Probation Office Team
Correctional Training Academy Team
Juvenile Justice Male Correctional Institution
Community Correctional Institution
Supermax Correctional Institution
Correctional Education Program of a State Correctional System
Correctional Mental Health Program of a State Correctional System
Medium/Minimum-Security Adult Female Institution
Large County Detention Center (County Jail)
Introduce your institution by identifying the following:
1) Name
2) Mission statement (if published)
3) Population served (number and demographics)
4) Examples of programs offered
5) Number of uniformed personnel and other staff members
Then develop a strategic plan considering the major themes of
Communication; Coordination (formal channels); and Cooperation (informal):
Include in your plan the following:
1) Four (4) organizational objectives (these can be future goals over a 1, 5, or 10-year period)
2) Strategies to address each of the objectives
3) At least 1 employee
or
inmate program that helps to achieve each objective
4) A method for assessing success for each objective
The final work product can include photographs, charts, graphics, or any other appropriate elements to enhance the effectiveness of your presentation
.
Find a listing of expenses by diagnosis or by procedure. The source .docxMalikPinckney86
Find a listing of expenses by diagnosis or by procedure. The source of the list can be internal (within a health care facility of some type) or external (such as a published article, report, or survey). Comment upon whether you believe the expense grouping used is appropriate. Would you have grouped the expenses in another way?
.
Financial Reporting Problem and spreedsheet exercise.This is an.docxMalikPinckney86
Financial Reporting Problem and spreedsheet exercise.
This is an comanding assignment. I am willing to pay good money because I need this assignment to be done correctly and on time. Please review the assignment before sending me an handshake.
**Serious inquires only***
Please see attachment for the assignment.
.
Find a Cybersecurity-related current event that happned THIS WEEK, a.docxMalikPinckney86
Find a Cybersecurity-related current event that happned THIS WEEK, activity, or development in the news. In your discussion post, briefly summarize the event and reflect on its significance. You should use any legitimate news source (television, internet, periodicals, etc.) to support your topical input.
Questions to address might include:
How does the event relate to issues addressed in class?
How might similar situations be mitigated?
What is the broader impact of the event (e.g., nationally, globally, etc.)
Include a link to the story or a citation so that others may read the story.
.
Financing Health Care in a Time of Insurance Restructuring Pleas.docxMalikPinckney86
The Affordable Care Act has significantly impacted health care insurance and coverage in the United States. It has increased the number of Americans with health insurance and prohibited denying coverage due to preexisting conditions. The ACA also changed how health care is provided by requiring most Americans to have qualifying health coverage or pay a penalty, expanding Medicaid, establishing health insurance marketplaces, and allowing children to stay on their parents' coverage until age 26.
Financing International Trade Please respond to the followingCom.docxMalikPinckney86
Two methods companies can use to finance international trade are obtaining financing from their own bank or keeping currencies on hand. Maintaining a portfolio of currencies has advantages like diversification but also risks from currency fluctuations. Companies can finance transactions through their bank by taking out loans denominated in foreign currencies. They can also hold marketable securities like foreign currency deposits. Interest rate parity and exchange rate forecasting methods affect short-term financing by influencing expectations of currency values over time, impacting decisions about currency hedging or borrowing in certain currencies.
Financial Statement Analysis and DisclosuresDiscuss the import.docxMalikPinckney86
Financial Statement Analysis and Disclosures
Discuss the importance of financial statement analysis, and determine why it is important to investors and creditors.
Imagine you are considering investing in a corporation.
Suggest what key information you would look for in a company’s financial statements, and explain why this information is important to you.
From the e-Activity, highlight the main elements that primary disclosure accounting policies encompass, and provide at least two (2) examples of the most commonly required disclosures.
Give your opinion on the way in which the disclosures you identified are important to financial statement users.
Provide a rationale for your opinion.
e-Activity
Go to the International Financial Reporting Standards (IFRS) Website to review authoritative guidance on “accounting policy disclosures”, located at
http://www.ifrs.org
in the search engine type in “accounting policy disclosures”.
Be prepared to discuss.
.
Financial Ratios what are the limitations of financial ratios .docxMalikPinckney86
Financial Ratios
what are the limitations of financial ratios? Classify your answer into at least the following categories: liquidity ratios, activity ratios, leverage ratios, and profitability ratios.
Financial Analysis
R.E.C. Inc.’s staff of accountants finished preparing the financial statements for 2010 and will meet next week with the company’s CEO as well as the Director of Investor Relations and representatives from the marketing and art departments to design the current year’s annual report. Write a paragraph in which you present the main idea(s) you think the company should present to shareholders in the annual report. Why do you think those ideas should be included?
.
Financial mangers make decisions today that will affect the firm i.docxMalikPinckney86
Financial mangers make decisions today that will affect the firm in the future. The dollars used for investment expenditures made today are different from the cash flows to be realized in the future. What are these differences? What are some of the techniques that can be used to adjust for these differences?
.
Financial Laws and RegulationsComplete an APA formatted 2 page pap.docxMalikPinckney86
Financial Laws and Regulations
Complete an APA formatted 2 page paper (not including the title and reference pages) answering the following questions:
What are five elements pertaining to the establishment of a false claim under the False Claims Act?
HIPAA privacy standards were designed to accomplish what three broad objectives? Explain each.
Stark II laws prohibit physician referrals to entities in which the physician has a financial relationship. What are 10 specific designated health services (DHS) for which referrals by physicians who have financial relationships with the entity providing the DHS are prohibited?
Discuss the following:
Qui tam
HIPAA Privacy Rule
EMTALA
Compliance programs
.
Financial Management DiscussionWhen reviewing the financial st.docxMalikPinckney86
Financial Management Discussion
When reviewing the financial statements of a company, there are many different ratios to choose from. Choose a ratio that looks at liquidity, solvency and profitability and discuss its importance.
75- 150 words required.
.
Final Written Art Project (500 words) carefully and creatively wri.docxMalikPinckney86
Final Written Art Project (500 words) carefully and creatively written words and sentences. Artist Statement (250 words)
WRITTEN ART PROJECT
Create a disjunctive or non-narrative piece
that engages all three aspects of reality that we have been discussing throughout the quarter: 1) larger political, social, and economic realities 2) personal or human dramatic situation and 3) detritus of existence. Make sure each of these are well represented and that they do not merely serve as a backdrop or props for other parts of your piece. In other words, make sure each of these aspects of reality is given its due as determining of your or others reality.
Possible Strategies and Advice:
Switch between first and third person perspectives. Make use of actual seeings—what you see. Describe and only occasionally explain or meditate. Meditate a great deal but be sure you are specific . Enact and don’t preach.
Create a concept (a title for your piece) that gives the reader a sense of the intent of your work.
This concept should serve to suggest complementary or conflictual relations between the different parts of your piece. Ultimately in placing all your parts together, in proximity to one another, you want the “whole” to be greater than the sum of the parts.
ARTIST STATEMENT
Please describe the intent of your piece and how you think its disjunctive form allows you to create a sense of reality that you wish to create. Please consider key words and concepts from the module syllabus as well as the ideas that have emerged from course discussions and thought challenges. You might also find these artist’s statements of use:
Chekov
Remove everything that has no relevance to the story. If you say in the first chapter that there is a rifle hanging on the wall, in the second or third chapter it absolutely must go off. If it’s not going to be fired, it shouldn’t be hanging there.
Marguerite Duras
Sometimes I realize that if writing isn’t, all things, all contraries confounded, a quest for vanity and void, it’s nothing. (
The Lover,
8)
Leslie Scalapino
I intended this writing to be the repetition of historically real events the writing of which punches a hole in reality. . . . There was when writing the work something else going interiorily besides what’s going on in segments.
.
Final Research Paper Research the responsibility of a critical t.docxMalikPinckney86
This document provides instructions for a final research paper asking students to research the responsibility of a critical thinker in contemporary society by examining a social issue through principles of critical thought, ethics, research-based truth seeking, and use of information technology. Students can choose a topic dealing with health, poverty, family relations, social media, immigration, or education issues.
Financial management homeworkUnit III Financial Planning, .docxMalikPinckney86
Financial management homework
Unit III
Financial Planning, the Financial System and Governance
Review:
Learning Activities (Non-Graded):
See Study Guide
Read:
Chapter 4:
Financial Planning
Chapter 5:
The Financial System, Corporate Governance, Interest, and the Financial Crisis of 2008
Submit:
.
Final ProjectThe Final Project should demonstrate an understanding.docxMalikPinckney86
Final Project
The Final Project should demonstrate an understanding of the reading assignments, class discussions, your own research and the application of new knowledge. It should utilize previous skills developed in foundational health care courses and apply them within the context and viewpoint of a health care administrator and their role in managing health and human services.
For the Final Project, select one of the following topics and conduct scholarly and professional research while integrating the course’s learning outcomes to address a selected topic:
Research specific leadership and management traits and theories necessary for managing a multidisciplinary and multicultural health care organization to promote organizational effectiveness.
Present how strategic planning, performance improvement, and information systems are interrelated and fundamental to the delivery of quality health care.
Examine the financial characteristics of health care delivery along with managing costs, revenues, and human resources.
Analyze ethical and legal concepts, including specific federal regulations, required of health care organizations to ensure the delivery of high quality health care that protects patient safety.
Research Requirements
Academic research and papers must meet certain standards of quality that are recognized by the academic community. What constitutes quality academic research?
The use of primary (original), credible sources written by experts in the field of study.
Ensuring secondary sources are supported by research in primary sources.
Making sure all research is relevant and that material used is pertinent to the area of study.
In graduate work, the use of peer-reviewed journal articles (journal articles reviewed by recognized experts in the relevant field of study) is required.
Keep in mind that educational websites may be appropriate, in some cases, but should be evaluated carefully.
The Ashford University Library offers many excellent databases and other resources to assist you in conducting scholarly research.
What sources are not acceptable for academic research and referencing?
Encyclopedias
Dictionaries
Wikipedia, other wikis, or blogs
Websites and other sources that do not provide quality researched materials (e.g., they do not use credible sources to support the information in the document).
All research must reflect professional academic protocol and must be documented according to APA standards as outlined in the Ashford Writing Center.
Creating the Final Project
You may choose to present your research is the form of an eight- to ten-page research paper (excluding title and reference pages) or a comprehensive 10- to 15-slide PowerPoint presentation (excluding title and reference slides) with detailed speaker notes. In either case, the content of the assignment must include each of the elements listed below:
Introduction
Describe the issue. Include why it was selected, the perspective of your appr.
Final ProjectImagine that you work for a health department and hav.docxMalikPinckney86
Final Project
Imagine that you work for a health department and have been asked to make a presentation to a group of health care professionals on the role and responsibilities of community and public health.
After reviewing the materials throughout the course and based on what you have learned, create a PowerPoint presentation of at least six slides that covers the following topics:
Describe the role of community and public health in the well-being of populations.
Describe the public health organizational structure.
Examine the legal and ethical dimensions of public and community health services.
Analyze funding of public and community health services.
Discuss the role of communication in community and public health programs.
Creating the Final Project
The Final Project:
Must be created using a screencast program such as Jing, Screencast-O-Matic, Screenr, or other audio/video program.
Must be a minimum of six PowerPoint slides in length (excluding title and reference slide), and formatted according to APA style as outlined in the Ashford Writing Center.
Must include a title slide with the following:
Title of presentation
Student’s name
Course name and number
Instructor’s name
Date submitted
Must include a succinct thesis that is presented on the opening slide.
Must address the topics with critical thought.
Must use at least four scholarly sources (not including the course text), including a minimum of two from academic journals found in the Ashford University Library. Other sources should be obtained from appropriate epidemiological information.
Must document all sources in APA style, as outlined in the Ashford Writing Center.
Must include a separate reference slide, formatted according to APA style as outlined in the Ashford Writing Center.
.
Thinking of getting a dog? Be aware that breeds like Pit Bulls, Rottweilers, and German Shepherds can be loyal and dangerous. Proper training and socialization are crucial to preventing aggressive behaviors. Ensure safety by understanding their needs and always supervising interactions. Stay safe, and enjoy your furry friends!
বাংলাদেশের অর্থনৈতিক সমীক্ষা ২০২৪ [Bangladesh Economic Review 2024 Bangla.pdf] কম্পিউটার , ট্যাব ও স্মার্ট ফোন ভার্সন সহ সম্পূর্ণ বাংলা ই-বুক বা pdf বই " সুচিপত্র ...বুকমার্ক মেনু 🔖 ও হাইপার লিংক মেনু 📝👆 যুক্ত ..
আমাদের সবার জন্য খুব খুব গুরুত্বপূর্ণ একটি বই ..বিসিএস, ব্যাংক, ইউনিভার্সিটি ভর্তি ও যে কোন প্রতিযোগিতা মূলক পরীক্ষার জন্য এর খুব ইম্পরট্যান্ট একটি বিষয় ...তাছাড়া বাংলাদেশের সাম্প্রতিক যে কোন ডাটা বা তথ্য এই বইতে পাবেন ...
তাই একজন নাগরিক হিসাবে এই তথ্য গুলো আপনার জানা প্রয়োজন ...।
বিসিএস ও ব্যাংক এর লিখিত পরীক্ষা ...+এছাড়া মাধ্যমিক ও উচ্চমাধ্যমিকের স্টুডেন্টদের জন্য অনেক কাজে আসবে ...
A review of the growth of the Israel Genealogy Research Association Database Collection for the last 12 months. Our collection is now passed the 3 million mark and still growing. See which archives have contributed the most. See the different types of records we have, and which years have had records added. You can also see what we have for the future.
How to Build a Module in Odoo 17 Using the Scaffold MethodCeline George
Odoo provides an option for creating a module by using a single line command. By using this command the user can make a whole structure of a module. It is very easy for a beginner to make a module. There is no need to make each file manually. This slide will show how to create a module using the scaffold method.
How to Add Chatter in the odoo 17 ERP ModuleCeline George
In Odoo, the chatter is like a chat tool that helps you work together on records. You can leave notes and track things, making it easier to talk with your team and partners. Inside chatter, all communication history, activity, and changes will be displayed.
Physiology and chemistry of skin and pigmentation, hairs, scalp, lips and nail, Cleansing cream, Lotions, Face powders, Face packs, Lipsticks, Bath products, soaps and baby product,
Preparation and standardization of the following : Tonic, Bleaches, Dentifrices and Mouth washes & Tooth Pastes, Cosmetics for Nails.
Assessment and Planning in Educational technology.pptxKavitha Krishnan
In an education system, it is understood that assessment is only for the students, but on the other hand, the Assessment of teachers is also an important aspect of the education system that ensures teachers are providing high-quality instruction to students. The assessment process can be used to provide feedback and support for professional development, to inform decisions about teacher retention or promotion, or to evaluate teacher effectiveness for accountability purposes.
Macroeconomics- Movie Location
This will be used as part of your Personal Professional Portfolio once graded.
Objective:
Prepare a presentation or a paper using research, basic comparative analysis, data organization and application of economic information. You will make an informed assessment of an economic climate outside of the United States to accomplish an entertainment industry objective.
it describes the bony anatomy including the femoral head , acetabulum, labrum . also discusses the capsule , ligaments . muscle that act on the hip joint and the range of motion are outlined. factors affecting hip joint stability and weight transmission through the joint are summarized.
This presentation was provided by Steph Pollock of The American Psychological Association’s Journals Program, and Damita Snow, of The American Society of Civil Engineers (ASCE), for the initial session of NISO's 2024 Training Series "DEIA in the Scholarly Landscape." Session One: 'Setting Expectations: a DEIA Primer,' was held June 6, 2024.
IFSM 301 – Week 4 Citations (NIST, 2009) (The six phas
1. IFSM 301 – Week 4 Citations
(NIST, 2009)
(The six phases of project management, n.d.)
(Waterfall versus Agile Project Management, n.d.)
(Gottesdiener, 2008)
(Value Attainment)
(Potts, 2008)
(Potts, Why You Shouldn't Have an IT Budget, 2008)
(UMUC Faculty)
Bibliography
Gottesdiener, E. (2008, March). Good Practices for Developing
User Requirements. The Journal
of Defense Software Engineering, 13-17. Retrieved January 25,
2021, from
https://learn.umgc.edu/d2l/le/content/541520/viewContent/2054
3074/View
NIST. (2009, April). The System Development Life Cycle.
Retrieved January 25, 2021, from
NIST:
https://learn.umgc.edu/d2l/le/content/541520/viewContent/2054
3036/View
2. Potts, C. (2008, November 15). It's Time to Change Your
Investment Culture. CIO, 24-26.
Retrieved January 25, 2021, from
https://learn.umgc.edu/d2l/le/content/541520/viewContent/2054
3105/View
Potts, C. (2008, May 15). Why You Shouldn't Have an IT
Budget. CIO, 74-76. Retrieved
January 25, 2021, from
https://learn.umgc.edu/d2l/le/content/541520/viewContent/2054
3106/View
The six phases of project management. (n.d.). Retrieved January
25, 2021, from University of
Maryland Global Campus:
https://learn.umgc.edu/d2l/le/content/541520/viewContent/2054
3072/View
UMUC Faculty. (n.d.). Performance Measures. Retrieved
January 25, 2021, from University of
Maryland Global Campus:
https://learn.umgc.edu/d2l/le/content/541520/viewContent/2054
3077/View
Value Attainment. (n.d.). Retrieved January 25, 2021, from
University of Maryland Global
Campus:
https://learn.umgc.edu/d2l/le/content/541520/viewContent/2054
3075/View
Waterfall versus Agile Project Management. (n.d.). Retrieved
January 25, 2021, from University
of Maryland Global Campus:
https://learn.umgc.edu/d2l/le/content/541520/viewContent/2054
3073/View
3. The System Development Life Cycle
For a brief overview of the System Development Life Cycle, the
following sections have been directly
quoted from the National Institute of Standards and Technology
(NIST) publication, The System
Development Life Cycle (SDLC). The entire NIST publication
is available at:
http://csrc.nist.gov/publications/nistbul/april2009_system-
development-life-cycle.pdf
"The system development life cycle is the overall process of
developing, implementing, and retiring
information systems through a multistep process from initiation,
analysis, design, implementation, and
maintenance to disposal. There are many different SDLC models
and methodologies, but each generally
consists of a series of defined steps or phases.
The System Development Life Cycle
Initiation Phase. During the initiation phase, the organization
establishes the need for a system and
documents its purpose.
Development/Acquisition Phase. During this phase, the system
is designed, purchased, programmed,
developed, or otherwise constructed. should be identified as
well.
4. Implementation Phase. In the implementation phase, the
organization configures and enables system
features, tests the functionality of these features, installs or
implements the system, and obtains a
formal authorization to operate the system. Design reviews and
system tests should be performed
before placing the system into operation to ensure that it meets
all required security specifications. In
http://csrc.nist.gov/publications/nistbul/april2009_system-
development-life-cycle.pdf
addition, if new controls are added to the application or the
support system, additional acceptance tests
of those new controls must be performed. This approach ensures
that new controls meet security
specifications and do not conflict with or invalidate existing
controls. The results of the design reviews
and system tests should be fully documented, updated as new
reviews or tests are performed, and
maintained in the organization’s official records.
Operations/Maintenance Phase. In this phase, systems and
products are in place and operating,
enhancements and/or modifications to the system are developed
and tested, and hardware and
software components are added or replaced. The organization
should continuously monitor
performance of the system to ensure that it is consistent with
pre-established user and system
requirements, and that needed system modificatio ns are
incorporated.
Configuration management (CM) and control activities should
be conducted to document any proposed
5. or actual changes to the system. Information systems are in a
constant state of evolution with upgrades
to hardware, software, firmware, and possible modifications in
the surrounding environment.
Documenting information system changes and assessing the
potential impact of these changes on the
system are essential activities to assure continuous monitoring,
and prevent problems.
Disposal Phase. In this phase, plans are developed for
discarding system information, hardware, and
software and making the transition to a new system. The
information, hardware, and software may be
moved to another system, archived, discarded, or destroyed. If
performed improperly, the disposal
phase can result in the unauthorized disclosure of sensitive data.
When archiving information,
organizations should consider the need for and the methods for
future retrieval.
Usually, there is no definitive end to a system. Systems
normally evolve or transition to the next
generation because of changing requirements or improvements
in technology.
The disposal activities ensure the orderly termination of the
system and preserve the vital information
about the system so that some or all of the information may be
reactivated in the future, if necessary.
Particular emphasis is given to proper preservation of the data
processed by the system so that the data
is effectively migrated to another system or archived in
accordance with applicable records
management regulations and policies for potential future
access."
6. 1/25/2021 Six Phases of Project Management - IFSM 301 6383
Foundations of Information Systems Management (2212)
https://learn.umgc.edu/d2l/le/content/541520/fullscreen/205430
72/View 1/8
1. The six phases of project management
This chapter provides a sketch of the traditional method of
project management. The model that is discussed here forms the
basis for all methods of project management. Later chapters go
into more depth regarding a model that is particularly
appropriate for IT-related projects.
Dividing a project into phases makes it possible to lead it in the
best possible direction. Through this organisation into
phases, the total work load of a project is divided into smaller
components, thus making it easier to monitor. The following
paragraphs describe a phasing model that has been useful in
practice. It includes six phases:
1. Initiation phase
2. Definition phase
3. Design phase
4. Development phase
5. Implementation phase
6. Follow-up phase
Figure 1: Project management in six phases, with the central
theme of each phase
https://www.projectmanagement-training.net/
https://www.projectmanagement-training.net/1-the-six-phases-
of-project-management/
8. Questions to be answered in the initiation phase include the
following:
Why this project?
Is it feasible?
Who are possible partners in this project?
What should the results be?
What are the boundaries of this project (what is outside the
scope of the project)?
The ability to say no is an important quality in a project leader.
Projects tend to expand once people have become excited
about them. The underlying thought is, While were at it, we
might as well Projects to which people keep adding objectives
and projects that keep expanding are nearly certain to go off
schedule, and they are unlikely to achieve their original goals.
In the initiation phase, the project partners enter a (temporary)
relationship with each other. To prevent the development of
false expectations concerning the results of the project, it makes
sense to explicitly agree on the type of project that is being
started:
a research and development project;
a project that will deliver a prototype or ‘proof of concept’;
a project that will deliver a working product.
The choice for a particular type of project largely determines its
results. For example, a research and development project
delivers a report that examines the technological feasibility of
an application. A project in which a prototype is developed
delivers all of the functionalities of an application, but they
need not be suitable for use in a particular context (e.g. by
hundreds of users). A project that delivers a working product
must also consider matters of maintenance, instructions and
9. the operational management of the application.
Many misunderstandings and conflicts arise because the parties
that are involved in a project are not clear on these matters.
Customers may expect a working product, while the members of
the project team think they are developing a prototype. A
sponsor may think that the project will produce a working piece
of software, while the members of the project team must first
examine whether the idea itself is technically feasible.
https://www.projectmanagement-training.net/category/six-
phases/
https://www.projectmanagement-training.net/category/boek/
https://www.projectmanagement-training.net/initiation-phase/
1/25/2021 Six Phases of Project Management - IFSM 301 6383
Foundations of Information Systems Management (2212)
https://learn.umgc.edu/d2l/le/content/541520/fullscreen/205430
72/View 3/8
1. The six phases of project management
Definition phase
After the project plan (which was developed in the initiation
phase) has been approved, the project enters the second phase:
the definition phase. In this phase, the requirements that are
associated with a project result are specified as clearly as
possible. This involves identifying the expectations that all of
the involved parties have with regard to the project result. How
many files are to be archived? Should the metadata conform to
the Data Documentation Initiative format, or will the Dublin
Core (DC) format suffice? May files be deposited in their
original format, or will only those that conform to the Preferred
10. Standards be accepted? Must the depositor of a dataset ensure
that it has been processed adequately in the archive, or is this
the responsibility of the archivist? Which guarantees will be
made on the results of the project? The list of questions goes on
and on.
Figure 2: Expectations of a project (Illustration: Rachèl
Harmsen)
It is important to identify the requirements as early in the
process as possible. Wijnen (2004) distinguishes several
categories
of project requirements that can serve as a memory aid:
Preconditions
Functional requirements
Operational requirements
Design limitations
Preconditions form the context within which the project must be
conducted. Examples include legislation, working-condition
regulations and approval requirements. These requirements
cannot be influenced from within the project. Functional
requirements are requirements that have to do with the quality
of the project result (e.g. how energy-efficient must an
https://www.projectmanagement-training.net/category/six-
phases/
https://www.projectmanagement-training.net/definition-phase/
https://www.projectmanagement-training.net/wordpress/wp-
content/uploads/2015/04/2.jpg
1/25/2021 Six Phases of Project Management - IFSM 301 6383
Foundations of Information Systems Management (2212)
11. https://learn.umgc.edu/d2l/le/content/541520/fullscreen/205430
72/View 4/8
automobile be or how many rooms must a new building have?).
Operational requirements involve the use of the project
result. For example, after a software project has been realised,
the number of malfunctions that occur must be reduced by
ninety per cent. Finally, design limitations are requirements that
involve the actual realisation of the project. For example,
the project cannot involve the use of toxic materials or
international partners for whom it is unclear whether they use
child
labour.
During the definition phase of a project that involved
developing a web application for a consortium of large
organisations,
no agreements were made concerning the browser that would be
supported by the application. The consortium assumed that
it would be Microsoft Explorer, because it was the browser that
everyone used. The programmers created the application in
Firefox, because they worked with the browser themselves and
because it had a number of functions that were particularly
useful during the development. Because most of the websites
that are made for Firefox also look good in Explorer, the
difference was initially not noticeable. Near the end of the
project, however, the customer began to complain that the
website
didn’t look good. The programmers, who had been opening the
site in Firefox, did not understand the complaint.
When the problem of the two browsers became clear, the
programmers reacted defensively, Can’t they just install
Firefox?
After all, it is free. The organisations, however, were bound to
the bureaucratic-minded system administrators who, for some
12. possibly justified reason, refused to install Firefox in addition
to Explorer. Even if they had wanted to install it, it would have
involved a lengthy process, and there would have been extra
costs for the time that the system administrators would have to
spend on the task. It was ultimately decided that the application
would have to be made suitable for Explorer. That involved
considerable extra work, whereby the project ran even more
behind schedule than it already had, and it was necessary to
negotiate the extra costs. It was later discovered that the various
organisations were working with different versions of
Microsoft Explorer.
It is very important that all parties that are involved in the
project are able to collaborate during the definition phase,
particularly the end users who will be using the project result.
The fact that end users are often not the ones that order the
project perhaps explains why they are often ignored. The client,
who pays for the project, is indeed invited to collaborate on
the requirements during the definition phase. Nonetheless, the
project result benefits when its future users are also invited.
As a point of departure, it is helpful to make a habit of
organising meetings with all concerned parties during the
definition
phase of a project.
During the development of an educational video game, the users
(young people) were involved in the project only at a later
stage. When the game was nearly completed, a group of young
people was asked to test the game. Their initial assessments
appeared mild and friendly. When pressed, however, they
admitted that they had actually found the game extremely
boring
and that they would certainly not play it themselves. Had these
young people been involved in the project earlier, the game
would probably have been a success. As it stands, the game
remains nearly unused on an Internet website.
13. The result of the definition phase is a list of requirements from
the various parties who are involved in the project. Every
requirement obviously has a reverse side. The more elaborate
the project becomes, the more time and money it will cost. In
addition, some requirements may conflict with others. New copy
machines are supposed to have less environmental impact;
they must also meet requirements for fire safety. The fire-safety
regulations require the use of flame-retardant materials,
which are less environmentally friendly. As this illustration
shows, some requirements must be negotiated.
Ultimately, a list of definitive requirements is developed and
presented for the approval of the projects decision-makers.
Once the list has been approved, the design phase can begin. At
the close of the definition phase, most of the agreements
between the customer and the project team have been
established. The list of requirements specifies the guidelines
that the
project must adhere to. The project team is evaluated according
to this list. After the definition phase, therefore, the customer
can add no new requirements.
A part of a new exhibit in a museum was comprised of a
computer installation, the creation of which had been project-
based.
Because there had been no definition phase in the project, no
clear agreements between the museum and those responsible
for building the installation had been made. When the computer
for the installation broke down halfway through the exhibit,
the museum assumed that it would be covered by the projects
guarantee. The project team had a different opinion.
Negotiations between the directors were necessary in order to
arrive at an appropriate solution.
1. The six phases of project management
14. https://www.projectmanagement-training.net/category/six-
phases/
1/25/2021 Six Phases of Project Management - IFSM 301 6383
Foundations of Information Systems Management (2212)
https://learn.umgc.edu/d2l/le/content/541520/fullscreen/205430
72/View 5/8
Design phase
The list of requirements that is developed in the definition
phase can be used to make design choices. In the design phase,
one or more designs are developed, with which the project
result can apparently be achieved. Depending on the subject of
the
project, the products of the design phase can include dioramas,
sketches, flow charts, site trees, HTML screen designs,
prototypes, photo impressions and UML schemas. The project
supervisors use these designs to choose the definitive design
that will be produced in the project. This is followed by the
development phase. As in the definition phase, once the design
has been chosen, it cannot be changed in a later stage of the
project.
Figure 3: Example: Global design for the DANS Architecture
Archive
In a young, very informal company, the design department was
run by an artist. The term design department was not
accurate in this case; it was more a group of designers who were
working together. In addition, everyone was much too busy,
including the head of the department.
15. One project involved producing a number of designs, which
were quite important to the success of the project. A young
designer on the project team created the designs. Although the
head of the design department had ultimate responsibility for
the designs, he never attended the meetings of the project team
when the designs were to be discussed. The project leader
always invited him, and sent him e-mails containing his young
colleagues sketches, but the e-mails remained unanswered.
The project leader and the young designer erroneously assumed
that the department head had approved the designs. The
implementation phase began. When the project was nearly
finished, the result was presented to the department head, who
became furious and demanded that it be completely redone. The
budget, however, was almost exhausted.
1. The six phases of project management
Development phase
https://www.projectmanagement-training.net/design-phase/
https://www.projectmanagement-training.net/wordpress/wp-
content/uploads/2015/04/3.jpg
https://www.projectmanagement-training.net/category/six-
phases/
https://www.projectmanagement-training.net/development-
phase/
1/25/2021 Six Phases of Project Management - IFSM 301 6383
Foundations of Information Systems Management (2212)
https://learn.umgc.edu/d2l/le/content/541520/fullscreen/205430
72/View 6/8
During the development phase, everything that will be needed to
implement the project is arranged. Potential suppliers or
16. subcontractors are brought in, a schedule is made, materials and
tools are ordered, instructions are given to the personnel
and so forth. The development phase is complete when
implementation is ready to start. All matters must be clear for
the
parties that will carry out the implementation.
In some projects, particularly smaller ones, a formal
development phase is probably not necessary. The important
point is
that it must be clear what must be done in the implementati on
phase, by whom and when.
1. The six phases of project management
Implementation phase
The project takes shape during the implementation phase. This
phase involves the construction of the actual project result.
Programmers are occupied with encoding, designers are
involved in developing graphic material, contractors are
building,
the actual reorganisation takes place. It is during this phase that
the project becomes visible to outsiders, to whom it may
appear that the project has just begun. The implementation
phase is the doing phase, and it is important to maintain the
momentum.
In one project, it had escaped the project teams attention that
one of the most important team members was expecting to
become a father at any moment and would thereafter be
completely unavailable for about a month. When the time came,
an
external specialist was brought in to take over his work, in
order to keep the team from grinding to a halt. Although the
team
17. was able to proceed, the external expertise put a considerable
dent in the budget.
At the end of the implementation phase, the result is evaluated
according to the list of requirements that was created in the
definition phase. It is also evaluated according to the designs.
For example, tests may be conducted to determine whether the
web application does indeed support Explorer 5 and Firefox 1.0
and higher. It may be determined whether the trim on the
building has been made according to the agreement, or whether
the materials that were used were indeed those that had
been specified in the definition phase. This phase is complete
when all of the requirements have been met and when the
result corresponds to the design.
Those who are involved in a project should keep in mind that it
is hardly ever possible to achieve a project result that
precisely meets all of the requirements that were originally
specified in the definition phase. Unexpected events or
advancing
insight sometimes require a project team to deviate from the
original list of requirements or other design documents during
the implementation of the project. This is a potential source of
conflict, particularly if an external customer has ordered the
project result. In such cases, the customer can appeal to the
agreements that were made during the definition phase.
As a rule, the requirements cannot be changed after the end of
the definition phase. This also applies to designs: the design
may not be changed after the design phase has been completed.
Should this nonetheless be necessary (which does sometimes
occur), the project leader should ensure that the changes are
discussed with those involved (particularly the decision-makers
or customers) as soon as possible. It is also important that the
changes that have been chosen are well documented, in order
to prevent later misunderstandings. More information about the
18. documentation of the project follows later in this handbook.
1. The six phases of project management
https://www.projectmanagement-training.net/category/six-
phases/
https://www.projectmanagement-training.net/implementation-
phase/
https://www.projectmanagement-training.net/category/six-
phases/
1/25/2021 Six Phases of Project Management - IFSM 301 6383
Foundations of Information Systems Management (2212)
https://learn.umgc.edu/d2l/le/content/541520/fullscreen/205430
72/View 7/8
Follow up phase
Although it is extremely important, the follow-up phase is often
neglected. During this phase, everything is arranged that is
necessary to bring the project to a successful completion.
Examples of activities in the follow-up phase include writing
handbooks, providing instruction and training for users, setting
up a help desk, maintaining the result, evaluating the project
itself, writing the project report, holding a party to celebrate the
result that has been achieved, transferring to the directors
and dismantling the project team.
The central question in the follow-up phase concerns when and
where the project ends. Project leaders often joke among
themselves that the first ninety per cent of a project proceeds
quickly and that the final ten per cent can take years. The
boundaries of the project should be considered in the beginning
of a project, so that the project can be closed in the follow -up
19. phase, once it has reached these boundaries.
It is sometimes unclear for those concerned whether the project
result is to be a prototype or a working product. This is
particularly common in innovative projects in which the
outcome is not certain. Customers may expect to receive a
product,
while the project team assumes that it is building a prototype.
Such situations are particularly likely to manifest themselves in
the follow-up phase. Consider the case of a software project to
test a very new concept.
There was some anxiety concerning whether any results would
be produced at all. The project eventually produced good
results. The team delivered a piece of software that worked
well, at least within the testing context. The customer, who did
not know much about IT, thought that he had received a
working product. After all, it had worked on his office
computer. The
software did indeed work, but when it was installed on the
computers of fifty employees, the prototype began to have
problems, and it was sometimes instable.
Although the programmers would have been able to repair the
software, they had no time, as they were already involved in
the next project. Furthermore, they had no interest in patching
up something that they considered a trial piece. Several
months later, when Microsoft released its Service Pack 2 for
Windows, the software completely stopped functioning. The
customer was angry that the product once again did not work.
Because the customer was important, the project leader tried
to persuade the programmers to make a few repairs. The
programmers were resistant, however, as repairing the bugs
would
cause too much disruption in their new project. Furthermore,
they perceived the software as a prototype. Making it suitable
20. for large-scale use would require changing the entire
architectural structure. They wondered if the stream of
complaints from
the customer would ever stop.
The motto, Think before you act is at the heart of the six-phase
model. Each phase has its own work package. Each work
package has its own aspects that should be the focus of
concentration. It is therefore unnecessary to continue discussing
what
is to be made during the implementation phase. If all has gone
well, this was already determined in the definition phase and
the design phase. For a more detailed description of the six-
phase model and the task packets for each phase, see Wijnen
(2004) and Kor (2002).
https://www.projectmanagement-training.net/follow-up-phase/
1/25/2021 Six Phases of Project Management - IFSM 301 6383
Foundations of Information Systems Management (2212)
https://learn.umgc.edu/d2l/le/content/541520/fullscreen/205430
72/View 8/8
1/25/2021 Waterfall versus Agile Project Management - IFSM
301 6383 Foundations of Information Systems Management
(2212)
https://learn.umgc.edu/d2l/le/content/541520/fullscreen/205430
73/View 1/13
Home Contact
21. 5. Waterfall versus Agile projectmanagement
The six-phase model is a waterfall model. In other words, the
phases take place in succession. Just as it is impossible to swim
upstream against a waterfall, the pure waterfall method does not
allow returning to a phase after it has been completed.
During the implementation phase, it is not desirable to decide to
adapt the design, thereby bringing implementation to a
standstill. For a number of reasons (see e.g. McConnell, 1996;
Kroll, 2004; Chromatic, 2003; Stapleton, 2002), the waterfall
method is usually less suited to software-development projects.
Software development is a creative process.
It is nearly impossible to identify all of the requirements
(functionalities) beforehand.
Estimating the amount of time that will be necessary to
implement a functionality is quite difficult.
It should be possible for all intermediate results to be tested by
users throughout the entire trajectory of the project.
Cyclical methods of project management
Conditions for cyclical project management
Risks of cyclical project management
5. Waterval versus Agile (cyclisch) project management
Software development is a creative process
To outsiders, software development appears to have more to do
with engineering than it does with inventing. It does,
however, correspond to inventing in a number of ways. In the
process of invention, one never knows in advance precisely
what is going to happen.
22. The designers and programmers who write new software must
conceive of solutions for the problems that are set before
them. Regardless of the many methods and prescriptions for
work, writing programming code remains largely new and
https://www.projectmanagement-training.net/
https://www.projectmanagement-training.net/contact/
https://www.projectmanagement-training.net/
https://www.projectmanagement-training.net/5-waterval-versus-
agile-cyclisch-projectmanagement/
https://www.projectmanagement-training.net/software-
development-is-a-creative-process/
https://www.projectmanagement-training.net/organizing-
requirements/
https://www.projectmanagement-training.net/estimating-time/
https://www.projectmanagement-training.net/testing-
intermediate-results/
https://www.projectmanagement-training.net/agile-cyclische-
projectmanagementmethodes/
https://www.projectmanagement-training.net/cyclical-methods/
https://www.projectmanagement-training.net/risks-of-cyclical-
methods/
https://www.projectmanagement-training.net/category/waterval-
versus-agile/
https://www.projectmanagement-training.net/software-
development-is-a-creative-process/
1/25/2021 Waterfall versus Agile Project Management - IFSM
301 6383 Foundations of Information Systems Management
(2212)
https://learn.umgc.edu/d2l/le/content/541520/fullscreen/205430
73/View 2/13
therefore largely uncertain. Programmers can choose their
23. solutions out of millions of possibilities that are written in
dozens
of programming languages, and which operate according to
thousands of hardware configurations and in dozens of software
platforms. Although this freedom does offer a number of
advantages, it also makes the project more difficult to manage
than
traditional projects (e.g. construction or building projects).
5. Waterval versus Agile (cyclisch) project management
It is nearly impossible to identify all of the requirements
(functionalities) beforehand
The waterfall method prescribes the formulation of
requirements as the project result of the definition phase.
Ideally, there
should be little further deviation from these requirements
throughout the rest of the project. The development of software
according to the waterfall method requires the investment of
considerable time in the beginning of the project in analysing
the necessary functionalities (requirements). This leads to a
functional design (for more details on functional designs, see
[i]). Using the functional design as a guide, the software
architect makes a technical design in the design phase. The
technical
design includes a description of how the desired functionalities
should be implemented.
Although this may appear quite straightforward, consider the
following situation (example adapted from McConnell, 1996, p.
138). There is a project to produce a new automobile. As an
active automobile driver, you are asked to formulate the
requirements for an automobile. You consult with other drivers
and create an extensive list:
24. The automobile must accommodate four people.
The automobile must have a steering wheel in the front on the
drivers left-hand side, a
brake pedal, a gas pedal and a hand brake.
The automobile must have four wheels.
The automobile must have white headlamps and red tail lamps.
et cetera (the actual list would obviously be enormous)
Using your list as a guide, the designers develop a new design,
which is subsequently built several months later. One day, as
you are walking down the street, you see an automobile
stopping. You realise that you neglected to include brake lamps
in
your list! You immediately telephone the engineer of the
automobile manufacturer, who nearly explodes in reaction to
your
call. You maintain that it is only a small change. For the
automobile manufacturers, however, it is a disaster. The
automobiles
that have already been made must be completely disassembled,
cables must be stretched from the brake pedals to the rear,
the rear of the automobile must be completely re-designed in
order to accommodate the brake lamps, the boot hatches that
had already been produced would have to be discarded and the
list goes on.
While the example above is somewhat absurd, it reflects an
almost daily reality in software development. Programmers
erroneously assume that the clients, customers or users of the
software that is to be developed know precisely what they want
Clients erroneously assume that the software builders can make
(and adapt) everything in the shortest possible time. This
problem is the greatest source of conflict between customers
and software builders.
The following anecdote illustrates the fact that there are many
25. conflicts between customers and software suppliers. A
beginning entrepreneur wanted to obtain legal insurance for his
business. He asked about the possibilities. When the broker
asked him to identify the sector in which his business was
active, the entrepreneur replied, ‘IT’. Too bad, replied the
broker,
‘there are so many lawsuits between IT suppliers and customers
that there are no insurance companies that will write legal -
insurance policies for IT companies’.
https://www.projectmanagement-training.net/category/waterval-
versus-agile/
https://www.projectmanagement-training.net/organizing-
requirements/
1/25/2021 Waterfall versus Agile Project Management - IFSM
301 6383 Foundations of Information Systems Management
(2212)
https://learn.umgc.edu/d2l/le/content/541520/fullscreen/205430
73/View 3/13
5. Waterval versus Agile (cyclisch) project management
Estimating the amount of time that will be necessary to
implement a functionality is quite difficult
The waterfall method assumes a number of phases. In their
project plans, project leaders must include estimates of the
amount of time (and therefore money) that will be needed for
each phase. We have already seen that time estimates are
generally difficult for any project, particularly if they must be
made in the early stages of a project. For software projects, it is
simply impossible. Imagine that it were feasible to compile a
qualitatively adequate list of functionalities in the definition
26. phase. In theory, the project team should then be able to provide
a reasonable estimate of how much time will be necessary to
implement each functionality. In practice, however, there are
too many uncertainties to allow a reasonable estimate (e.g.
McConnell, 1996):
Once a functionality has been made, it is often discovered that
the customer does not need it after all. The hours that
were used in implementing this functionality can therefore be
regarded as useless.
Requirements change during the project.
Should the functionality be implemented expensively or
inexpensively? There are many possible methods of
implementation and realisation.
How will the functionality be designed technically? The design
largely determines the amount of time that will be
needed to make it.
How high must the quality of the functionality be? For example,
should a web application always remain completely
available, or can it be offline for a few hours each year?
The time needed to identify and repair errors in software can
vary from minutes to weeks.
How long will it take to install and integrate the new software
into the customers existing systems?
The lack of knowledge concerning possible solutions also
complicates the estimation of time. Further, it is difficult to
estimate how long it will take to acquire the necessary
knowledge.
The list above shows that many factors can affect the amount of
time that will ultimately prove necessary to implement a new
piece of software. Research (McConnell, 1996, p. 168) has
shown that the estimates of the time needed to implement a
functionality at the beginning of a project varies between four
times too little time and four times too much time. This means
that the amount of time necessary can turn out to be either four
27. times higher or four times lower than a faulty estimate.
These estimates become more accurate as the project
progresses. After the functional design has been made, the
margin is
reduced to twenty-five per cent too much or too little. Only
when the functionality is implemented can an estimate be
provided with a high level of certainty (see Figure 8).
https://www.projectmanagement-training.net/category/waterval-
versus-agile/
https://www.projectmanagement-training.net/estimating-time/
1/25/2021 Waterfall versus Agile Project Management - IFSM
301 6383 Foundations of Information Systems Management
(2212)
https://learn.umgc.edu/d2l/le/content/541520/fullscreen/205430
73/View 4/13
Figure 8: Accuracy of estimates of time necessary to implement
a functionality (Source: McConnell, 1996, p. 168).
Software is never completely free of errors. Even for the well -
known packages that are used by many (e.g. Word, Excel,
Explorer, OSX, PHP, Flash), there are lists of known bugs
available on the Internet. New releases regularly appear on the
market, in which software errors have been removed. Customers
sometimes expect error-free software. In practice, however,
such a goal would make it impossible to complete a piece of
software. Moreover, software errors are often not inherent in the
software itself.
An educational game was made in Flash. It was agreed that the
28. game would be delivered as a file and that the customer
would install it himself on his own server. During the project,
the customer requested that a high score feature be included in
the game to increase competition between players. This would
require a piece of script code in PHP. The game builder s made
and tested the script code on their own server, which worked in
Linux. It worked. The game and script code were delivered to
the customer. The customer, however, had a Windows server
and, for some reason, the script no longer worked well. The
high scores were not saved. The programmer eventually needed
a week to resolve the problem. As it turned out, the
combination of PHP and Windows does not always work well.
The script itself contained absolutely no errors! By using a
hack, he was able to get it to work, and everyone was satisfied
but who should pay for that extra week of work?
Another software-development project also involved
educational software. The problem was that the software worked
for the
programmers, but it did not work well for the customer. After
trying nearly everything, the programmer decided to pay a visit
to the customer. As it turned out, the customer was using an old
Pentium III system. The slowness of the computer caused
the poor performance of the software. The programmers had
also tested the software on a Pentium III, but it had worked
fine. Further investigation revealed that the customers computer
was so slow because it was full of viruses and spyware.
The uncertainty that is illustrated by the examples above does
not simplify the writing of project plans. It also complicates
agreements between the parties involved. Someone must assume
the risks for extra work that must be done. If payment is on
an hourly basis, the customer assumes the risk. If a fixed price
has been agreed (as in grant-funded projects), the software
builder assumes the risk. When more than two parties are
involved, it becomes even more complicated. In such a case,
29. who
should pay for the extra hours in the project?
Discussions often arise concerning who should be responsible
for delays. In many cases, the guilty party is difficult to
identify. It is quite possible that none of the parties involved is
at fault, as the delay is actually the result of a faulty initial
estimate of the number of hours that would be needed.
Exceeding the number of project hours and the question of who
should pay are frequent sources of conflict in the IT world.
https://www.projectmanagement-training.net/wordpress/wp-
content/uploads/2015/03/8.jpg
1/25/2021 Waterfall versus Agile Project Management - IFSM
301 6383 Foundations of Information Systems Management
(2212)
https://learn.umgc.edu/d2l/le/content/541520/fullscreen/205430
73/View 5/13
5. Waterval versus Agile (cyclisch) project management
It should be possible for all intermediate results to be tested by
users throughout the entire
trajectory of the project
It should be possible for all intermediate results to be tested by
users throughout the entire trajectory of the project
In the definition phase and the design phase, customers are
asked to formulate their requirements as well as possible. This
is
difficult for two reasons. First, customers have only a limited
conception of the possibilities or impossibilities of IT. They do
30. not have a good idea of what is or should be possible or what
they should or should not want. Second, customers often have
only limited knowledge of their own business processes. Many
IT projects involve the computerisation of a customers
existing business practices. Even though customers may have
worked with the processes for many years, they are often not
able to define their own business processes. They can work fine
in their own way, but cannot say exactly what that way is. The
precise definition of processes is a precondition for making
software that will drive computerisation. The complexity for
customers thus increases if they must describe existing
processes.
The list of requirements that is developed in the definition
phase is often incomplete. In the implementation phase,
programmers make software according to this incomplete list.
When users are confronted with the initial versions of the new
software, additional requirements are identified. It looks good,
but now can you make it so that I don’t have to keep entering
my password? Programmers often complain that customers do
not know what they want. Customers appeal to the fact that,
because software developers are professionals, they should have
determined earlier in the process what the customers
wanted.
In a software project that involved the automatic processing of
applications for a web-based service, an extensive functional
design was made. Long lists of requirements from the customer
were compiled. A number of screen designs and flow charts
were added, after which the programmers could get started.
Probably because the project was under extreme time pressure
or perhaps because the customers organisation was rather
chaotic, the designers had neglected to include one important
component: manual administration. The applications were
processed by the software. Because the processing of the
applications was to be automatic, the programmers thought that
31. no manual administration would be desired. This
requirement also did not appear in the functional design. When
the software was delivered for testing, the customer realised
that there were exceptions in some of the applications. These
applications could not be processed automatically, but would
have to be handled manually. The software, however, worked
only automatically.
In the waterfall method, the actual project result is tested at the
end of the implementation phase. This is late in the
development process. The time between the definition phase,
design phase and implementation phase sometimes amounts to
months or even more than a year. If design errors are discovered
in a late stage of the project, it can be expensive or
sometimes even impossible to adapt software without beginning
an entirely new project. Because we have seen that it is
practically impossible to specify all requirements beforehand, a
working method that allows the possibility of testing
(intermediate) results earlier is desirable.
Comparing a number of prospective software houses, a customer
asked the competing parties what was possible. One party
was somewhat reserved and doubted whether some of the
customers requests would be feasible. The other party had an
aggressive sales representative. When the customer asked the
sales representative if a particular request would be possible,
the sales representative telephoned his programmers. Can we
build a functionality that can do X? The programmer, who
thought primarily in technical terms, answered that, in
principal, anything was possible. Neither the programmer nor
the
sales representative worried about feasibility in terms of projec t
management (e.g. time, money, complexity, risk).
https://www.projectmanagement-training.net/category/waterval-
versus-agile/
32. https://www.projectmanagement-training.net/testing-
intermediate-results/
1/25/2021 Waterfall versus Agile Project Management - IFSM
301 6383 Foundations of Information Systems Management
(2212)
https://learn.umgc.edu/d2l/le/content/541520/fullscreen/205430
73/View 6/13
The sales representatives enthusiasm was more effective than
the other parties reserved attitude had been. The customer
chose the aggressive sales representatives offer. The newly
acquired project subsequently came into the hands of a project
leader and a group of programmers. After a time, it became
apparent that the project did not fulfil the customers
expectations. This had partially to do with the fact that the
processes were much more complicated for the customer than
they had originally appeared. During a heated discussion
between the two parties, the customer referred to the fact that
the
sales representative had said that functionality X would not be a
problem.
5. Waterval versus Agile (cyclisch) project management
Conditions for cyclical project management
To apply cyclical project management, a number of conditions
must be met:
1. Users/customers are actively involved.
In cyclical project management, the formulation of
requirements, design, implementation and testing take place in
each
33. cycle. This means that many decisions must be taken in a cycle.
If the software is to provide a good reflection of the wishes of
the customer, the customer must participate actively in the
project team. Customers must present their wishes as clearly as
possible to the programmers and designers. This generally
involves weekly (or at least bi-weekly) presence in the project
team.
Within a project, customers are involved with determining the
desired functionalities and the planning of the cycles. They
collaborate on the acceptance tests, approve or reject
intermediate results and collaborate on the general direction of
the
project. The active involvement of the customer also leads to
better results in the waterfall method.
2. The team is authorised to take decisions.
Within a cycle, the project team must be authorised to do what
they think is best. If the project team does not have this
power, the cyclical model of project management will not work.
If constant authorisation from superiors is necessary during
a cycle, this can lead to stagnation. Moreover, outsiders are
often poorly informed about what is going on, because they do
not actively participate in the project team; this makes it
difficult for them to make sensible decisions.
3. Project result (software) can be broken down into smaller
parts.
With cyclical project management, parts of the project are
performed in a number of cycles. This is possible only if the
software that is to be created is divisible into a number of more
or less separate components.
34. 4. The requirements that are imposed by management with
regard to the software are primarily global; management does
not impose direct, concrete or specific requirements. One of the
strengths of cyclical project management is that the
customer, designers, programmers and any testers work closely
together within the cycles. If there are already specific and
concrete requirements at the beginning of a project, this
impedes the freedom of the project team to use their better
judgment to make design choices. Many requirements on a
project are revealed during the process to be in need of
adaptation and should therefore not be (too) firmly established
in the beginning.
5. The activities are intelligible for the customer.
If considerable technical work that is difficult for the customer
to understand must take place within a cycle, a risk emerges
that the customer will not be in state to participate well in the
team. In such a situation, the customer has very little to
contribute to the necessary design choices.
https://www.projectmanagement-training.net/category/waterval-
versus-agile/
https://www.projectmanagement-training.net/cyclical-methods/
1/25/2021 Waterfall versus Agile Project Management - IFSM
301 6383 Foundations of Information Systems Management
(2212)
https://learn.umgc.edu/d2l/le/content/541520/fullscreen/205430
73/View 7/13
A similar risk arises when the progress is not visible to the
customer. For example, much of the work may involve coding,
with very little being done on the user interface. It is important
35. that customers have sufficient insight into the substance and
progress of a cycle in order to ensure that they are not pushed
into the background.
6. It should be possible to take a step backwards.
Even in cyclical project management, teams sometimes pursue
paths that later prove to have been wrong. In such a case, it
should be possible to take a step backwards. If a new module
that is created in a cycle proves inadequate, it must be possible
to resume working with the old module. This imposes demands,
particularly with regard to the archival and documentation
of the project materials. Concurrent Versioning System (CVS)
and Subversion are two helpful tools for these tasks
(see Appendix 3 for a list of tools).
7. In addition to programming, programmers should be able to
communicate with customers, and vice versa. Team members
must be in state to think conceptually. Discipline is necessary in
order to persevere with the work.
8. The organisation in which the project takes place must also
offer sufficient support for this method of working. Systems for
time reporting, archiving and scheduling are necessary to
support the projects. These registration systems ensure the
transparency that is necessary to ensure the adequate
distribution of resources across projects and time.
9. Projects should have sufficient priority, team members must
be released for projects. Requiring team members to work in
too many projects at the same time does not work. If an
organisation is insufficiently adjusted to working with projects,
the
flexibility of cyclical project management is likely to lead to
chaos. The waterfall method also benefits from an organisation
that is arranged for working with projects (see Wijnen, 2004, p.
36. 111).
The director of a software house, who was more of a visionary
than he was a manager, had a brilliant idea nearly every
month, and he was continually starting new projects in his
company. Older projects were consequently never completely
finished, and the employees were sometimes working on as
many as five projects at once. The charismatic director had once
read a book on rapid application developme nt (RAD) and was
quite enthusiastic about it particularly about the aspect of
rapid. He posted the basic concepts of RAD over the copier and
subsequently assumed that everyone would start working
according to these concepts. After all, it was a wonderful
method.
5. Waterval versus Agile (cyclisch) project management
Cyclical methods of project management
Because of the issues that have been sketched above, a number
of other methods of project management have emerged in
recent years. These methods are particularly suited for IT-
development projects. Examples of these relatively new streams
within project management include DSDM, RUP, eXtreme
Programming (XP), RAD and agile project management
(McConnell, 1996; Kroll, 2004; Chromatic, 2003; Stapleton,
2002, [ii], [iii])
Although the above-mentioned methods of project management
differ according to a number of aspects, they are essentially
the same. Because the path toward the final goal of IT projects
has proved so uncertain, these methods assume that the goal
will be achieved in a number of short cycles. This is the
background for the term cyclical project management for these
methods.
37. https://www.projectmanagement-training.net/appendix-3-
resources-project-management/
https://www.projectmanagement-training.net/category/waterval-
versus-agile/
https://www.projectmanagement-training.net/agile-cyclische-
projectmanagementmethodes/
1/25/2021 Waterfall versus Agile Project Management - IFSM
301 6383 Foundations of Information Systems Management
(2212)
https://learn.umgc.edu/d2l/le/content/541520/fullscreen/205430
73/View 8/13
Figure 9: The activities in a cycle
In cyclical project management, the project goal is pursued in
several short, successive consecutive cycles. Each cycle is
relatively short, preferably lasting less than one month. Within
each cycle, a portion of the project is carried out. Analysis,
design, implementation and testing occur within each cycle.
This is fundamentally different from the waterfall method, in
which these activities all take place within their own separate
phases. In addition, the waterfall method prescribes only single
moments for definition, design, implementation and testing. In
the cyclical method, this occurs many times in sequence.
Various components of the software are implemented during the
cycles, which are therefore independent of each other.
Evaluation takes place after each cycle is completed. Should
advancing insight lead to new of different requirements for the
project, the activities of the subsequent cycles are adapted to
take them into account.
38. A cycle begins with the making or adjusting of the schedule.
Next, the requirements of the result of the cycle are examined.
A
design is made, programmed and tested. Evaluation
subsequently occurs and, in some methods, the new software is
brought
into use. Thereafter, the following cycle can begin, in order to
carry out the following component of the project. (For a more
extensive description of cyclical methods and the differences
between the methods, see e.g. Kroll, 2004; Chromatic, 2003;
Stapleton 2002.)
The most important advantages of working with the cyclical
method are as follows:
Higher product quality and improved implementation of
functionalities,
More realistic estimates of time and money,
Project team is under less pressure,
Higher quality.
The previous chapters have shown that it is difficult or
impossible to determine of the desired functionalities accurately
in the
early stages of a project. In cyclical methods, the desired
functionalities are implemented in several short cycles. In each
cycle, a small portion of the desired functionality is not only
investigated; it is designed, implemented and tested as well. The
short succession of design, implementation and testing makes a
particularly important contribution to quality improvement.
Teams are thereby in state to make adjustments. If a design does
not turn out to be good in practice, it becomes obvious
during the cycle, thereby allowing adjustment. This way of
working also allows customers to request adjustments.
39. Another reason that cyclical project management leads to better
quality is that a cycle involves intensive collaboration
between customer, designers and programmers. A multi-
disciplinary team jointly conceives of and implements solutions.
In
the waterfall method, the customer is involved primarily in the
beginning, in the formulation of the requirements; thereafter,
the designers make a design and then the programmers
programme the software. The project leader serves as the link
between all of the various parties and must ensure that
information that is exchanged is delivered to the right place. In
practice, many programmers and designers never see the
customer, who re-emerges in the process only after the software
has
been completed.
Cyclical methods of project management are particularly suited
to projects in which the goal that is to be achieved cannot be
clearly established beforehand, as in creative projects or
research projects. Working in a number of cycles with a multi -
disciplinary team in which the end-users are also represented
allows the team to discover the real goal of the project and how
it can best be achieved. Each cycle contains a point for
reflection and an opportunity for adjustment.
https://www.projectmanagement-training.net/wordpress/wp-
content/uploads/2015/03/9.jpg
1/25/2021 Waterfall versus Agile Project Management - IFSM
301 6383 Foundations of Information Systems Management
(2212)
https://learn.umgc.edu/d2l/le/content/541520/fullscreen/205430
73/View 9/13
40. In waterfall projects, a goal is formulated beforehand.
Reflection on the original goal is less of a possibility. The
originally
formulated goal is never (fully) achieved, and it is likely that
neither the originally formulated goal nor the goal that is
achieved is exactly what was originally desired.
Figure 10: Better results are achieved by working in cycles.
(Illustration: Rachèl Harmsen)
The last reason why cyclical project techniques generate better
results is that the customer performs acceptance tests. Quality
is further strengthened by using tests as criteria for well -
performing functionality from the very beginning. Programmers
must therefore define failing tests (or unit tests) before they
write their code. The code is considered acceptable only if it
passes the failing test.
Test-oriented work requires programmers to prove that there are
no bugs in the new code before they write new code. They
do this by developing a test (failing test) that would detect any
possible bugs before they begin coding. For example, imagine
that a programme must be written for calculating the correct
amount of change that you must receive from a candy machine.
First, the availability of a function to give change must be
tested. This function could be called give_change. A simple test
could be made and, when it is performed, it is determined that a
give_change function does not yet exist. If the programmer
then makes the function but does not yet give it any substance,
the test will succeed.
The next step would be to test whether the machine gives the
right amount of money back when an item is purchased. Insert
sixty cents into the machine and buy an item that costs fifty
cents. The test will not succeed, because the function is still
41. empty. The programmer then writes the code. In the
give_change function, he writes that the amount of change to be
returned is the amount of money that was inserted in the
machine, less the price of the chosen candy. The test should
now
succeed. The process continues in this way; for each component
of the software, a test must be devised beforehand (example
translated and adapted from Chromatic, 2003, p. 27 ff).
The code is not the only component that must be technically
tested; the functionalities must also be tested (i.e. acceptance
tests). For these tests, the customer determines the conditions
under which the functionalities that are to be built can be
accepted, before coding begins (e.g. how quickly a computer
must respond to a certain action of a user). The prior
specification of the conditions under which the new
functionality can be accepted has proven particularly difficult
and time-
consuming. Nonetheless, the active role of customers in testing
is an important determinant in the success of a project.
More realistic estimation of time and money
With cyclical project techniques, the functionalities that are to
be implemented are not written in stone at the beginning of
the project. The available time is specified. Agreements are
made concerning the direction in which the project will
proceed,
and it is determined in the process what is actually needed,
useful and realistic with regard to the software that is to be
made.
In cyclical projects, the functionalities that are to be
implemented are not established as fixed goals, and they thus
avoid the
risk that the necessary hours, and therefore money, can get
entirely out of hand. To prevent such a situation, the available
42. time is used as a starting point, and it is determined during the
process what is realistic to expect in that amount of time. Also
for this reason, cyclical methods of project management are
much friendlier for the project team. The team does what it can
do within the specified time, but is not pressured to meet
unrealistic schedules or to work within an inadequate budget.
Cyclical methods also facilitate the management of external
suppliers. With the waterfall method, a project can become
bound to a single supplier until the end of the project,
regardless of the performance of that supplier. In the cyclical
working
https://www.projectmanagement-training.net/wordpress/wp-
content/uploads/2015/03/10.jpg
1/25/2021 Waterfall versus Agile Project Management - IFSM
301 6383 Foundations of Information Systems Management
(2212)
https://learn.umgc.edu/d2l/le/content/541520/fullscreen/20 5430
73/View 10/13
method, is theoretically possible to make new agreements for
each cycle or even for each component to be delivered and, if
necessary, to change suppliers.
5. Waterval versus Agile (cyclisch) project management
Risks of cyclical project management
Cyclical methods of project management sometimes allow
insufficient time to implement the desired functionalities.
Because
the amount of time is pre-determined, fewer functionalities will
43. probably be made than were originally assumed.
This is indeed a real risk, but it is also inherent in the waterfall
method. In the waterfall method, the definition phase includes
an extensive analysis of requirements. This analysis could be
expected to generate better time planning. This is often not the
case in practice, however, for the reasons that are mentioned
above. Functionalities are left out in this method as well, as
there is not enough money to implement them.
In cyclical methods, requirements are handled pragmatically.
For example, the requirements in cycles can be divided
according to the MoSCoW rules (Stapleton, 2003):
Must Have: requirements that are essential for the system
Should Have: important requirements that people really want
Could Have: requirements that are desirable, but which can be
easily omitted
Want to Have: but will not have this time round: requirements
that can wait until later
Regardless of the fact that there may be no more time for
particular functionalities, the DANS project managers agree that
cyclical work yields more customer satisfaction than the
waterfall method does. At any rate, the expectations are
consistently
better managed, and the projects deliver results that actually
work, even if they are less elaborate than originally hoped.
One frequently mentioned disadvantage of XP is that
considerable power comes to rest with the programmers. If they
misuse
this power, they can hide behind the customers lack of technical
knowledge. Preventing this situation requires a project
leader who can serve the interests of both the programmers and
44. the customer. Such project leaders assist their customers in
choosing and planning the cycles, making the technical
background of choices intelligible and providing for
administration
and reporting.
Finally, another disadvantage of XP is that there is a steep
learning curve for programmers, managers and customers with
regard to the introduction of the method.
5. Waterval versus Agile (cyclisch) project management
https://www.projectmanagement-training.net/category/waterval-
versus-agile/
https://www.projectmanagement-training.net/risks-of-cyclical-
methods/
https://www.projectmanagement-training.net/category/waterval-
versus-agile/
1/25/2021 Waterfall versus Agile Project Management - IFSM
301 6383 Foundations of Information Systems Management
(2212)
https://learn.umgc.edu/d2l/le/content/541520/fullscreen/205430
73/View 11/13
1. The six phases of project management
Initiation phase
Definition phase
Design phase
Development phase
45. Implementation phase
Follow up phase
2. Managing a project
Time
Money
Quality
Organisation
Information
3. Project reporting
4. The sales representative and the politician
5. Waterval versus Agile (cyclisch) project management
Creative proces
Organizing requirements
Estimating time
Testing intermediate results
Cyclical methods
Conditions for cyclical methods
Risks of cyclical methods
46. 6. DANS software-development method
7. Programme management
Appendix
Appendix 1: Causes delays IT projects
Appendix 2: Roles within a project
Appendix 3: Resources project management
Appendix 4: License handbook
Appendix 5: DANS and makers of handbook
Appendix 6: Action-and-decision list
Appendix 7: Sample Issue log
Appendix 8: Sample Risk log
Appendix 9: Sample meeting report
Appendix 10: Sample project plan
https://www.projectmanagement-training.net/category/six-
phases/
https://www.projectmanagement-training.net/initiation-phase/
https://www.projectmanagement-training.net/definition-phase/
https://www.projectmanagement-training.net/design-phase/
https://www.projectmanagement-training.net/development-
phase/
https://www.projectmanagement-training.net/implementation-
phase/
50. https://www.projectmanagement-training.net/articles/project-
management-tools/
1/25/2021 Waterfall versus Agile Project Management - IFSM
301 6383 Foundations of Information Systems Management
(2212)
https://learn.umgc.edu/d2l/le/content/541520/fullscreen/205430
73/View 13/13
March 2008 www.stsc.hill.af.mil 1 3
Many software developers have a love-hate relationship with
requirements.
They love having a list of things they need
to engineer into the product they are
building, but they hate it when the require-
ments are unclear, inaccurate, self-contra-
dictory, or incomplete. They are right to
be concerned.
The price is high for teams that fail to
define requirements or that do it poorly.
Ill-defined requirements result in require-
ments defects, and the consequences of
these defects are ugly [1- 6]:
• Expensive rework and cost overruns.
• A poor quality product.
• Late delivery.
• Dissatisfied customers.
• Exhausted and demoralized team
members.
51. To reduce the risk of software project
failure and the costs associated with defec-
tive requirements, project teams must
address requirements early in software
development and they must define
requirements properly.
A Short Review of
Requirements
Before we get to the nitty-gritty of build-
ing requirements models, let us look at
some basic requirements concepts. User
requirements – the focus of this article –
are one of three types of requirements
(see Figure 1). The other two types are
those related to the mission or business
and those that describe the software itself.
Business requirements are statements of
the business rationale for the project.
These requirements grow out of the
vision for the product which, in turn, is
driven by mission (or business) goals and
objectives. The product’s vision statement
articulates a long-term view of what the
product will accomplish for its users. It
should include a statement of scope to
clarify which capabilities are and are not to
be provided by the product.
User requirements define the software
requirements from the user’s point of
view, describing the tasks users need to
accomplish with the product and the qual-
52. ity requirements of the software from the
user’s point of view. Users can be broadly
defined to include not only the people
who access the system but also inanimate
users such as hardware devices, databases,
and other systems. In the systems pro-
duced by most government organizations,
user requirements are articulated in their
concept of operations document.
Software requirements are detailed
descriptions of all the functional and non-
functional requirements the software must
fulfill to meet business and user needs.
Nonfunctional requirements include soft-
ware design constraints, external inter-
faces, and quality attributes such as per-
formance, security, installation ability,
availability, safety, reusability, and more [7].
Software requirements, which are docu-
mented in a software requirements specifi-
cation, establish an agreement between
technical specialists and business man-
agers on what the product must do.
The key activities in requirements
development are the following: elicitation,
analysis, specification, and validation [8]. In
elicitation, you identify the sources of
requirements and solicit requirements
from those sources. Requirements elicita-
tion relies on appropriate stakeholder
involvement, one of the most critical ele-
ments for project success [9]. The goal of
requirements analysis is to sufficiently
55. requirements with your stakeholders.
As you elicit requirements from stake-
holders and represent them using require-
ments models, you should verify your
models to ensure they are internally con-
sistent. You also need to prioritize your
requirements: With active user involve-
ment, you analyze the trade-offs among
requirements to establish their relative
importance [8].
The User Requirements
Model Roadmap
Now let us take a closer look at user
requirements models. The beauty of the
Requirements Model Road Map (Figure 2)
is that it shows the relationships between
the three types of requirements (business,
user, and software) and categorizes the
models you can use to represent each type.
Each model is designed to answer one of
the 5Ws + 1H questions: Who? What?
When? Why? How? [7].
(Note that the question Where? pro-
vides information mainly about nonfunc-
tional requirements. Although these are not
user requirements – which depict function-
al requirements – analysts asking Where?
during analysis will also discover a slice of
useful quality attributes such as perfor-
mance and usability).
In addition, the user requirements
model falls into three categories: scope,
56. high-level and detailed, and alternative
models. Some models (shown in italics in
Figure 2) are useful for analyzing the busi-
ness process, and others are useful for clar-
ifying project scope. Defining stakeholder
categories early in elicitation, for example,
identifies the people you should involve in
requirements modeling. High-level and
detailed models, such as use cases, a data
model, and business rules, can reveal
requirements defects such as errors, omis-
sions, and conflicts. Requirements analysts
and engineers can substitute alternative
models when the engineers better commu-
nicate requirements or fit the project cul-
ture.
Each requirements model represents
information at a different level of abstrac-
tion. A model such as a state diagram rep-
resents information at a high level of
abstraction, whereas detailed textual
requirements represent a low level of
abstraction. By stepping back from the
trees (textual requirements) to look at the
forest (a state diagram), the team can dis-
cover requirements defects not evident
when reviewing textual requirements alone.
Because the requirements models are
related, developing one model often leads
to deriving another. Examples of one
model driving another model are the fol-
lowing:
• Actors initiate use cases.
57. • Scenarios exemplify instances of use
cases.
• A use case acts upon data depicted in
the data model.
• A use case is governed by business
rules.
• Events trigger use cases.
In this way, you can use various routes
to harvest one model from another. This
approach helps you develop the models
quickly while at the same time verifying
the model’s completeness and correctness.
User Requirements Models
Here, in alphabetical order, are brief
descriptions of the common user require-
ments models shown in the User
Requirements Models Road Map.
Activity Diagram
An activity diagram is a model that illus-
trates the flow of complex use cases using
Unified Modeling Language (UML) nota-
tion. This model is useful for showing use
case steps that have multiple extension
steps, and for visualizing use cases.
Actor Map
An actor map is a model that shows actor
interrelationships. An actor map supple-
ments the actor table and can also be used
58. as a starting point for identifying use cases.
Actors can be written on index cards (one
per index card) or drawn using the UML
notation. UML depicts actors in an actor
map as stick figures, as boxes (supplement-
ed by the notation “<<Actor>>”), or as a
combination (e.g., stick figures for human
actors, and boxes for nonhuman actors).
Actor Table
An actor table is a model that identifies and
classifies system users in terms of their
roles and responsibilities. This model helps
reveal missing system users and identifies
functional requirements as user goals (use
cases), and also management to clarify job
responsibilities.
Business Policies
Business policies are guidelines, standards,
and regulations that guide or constrain the
conduct of a business. Policies are the basis
for the decision making and knowledge that
are implemented in the software and in
manual processes. Whether imposed by an
outside agency or from within the company,
policies are used to streamline operations,
increase customer satisfaction and loyalty,
reduce risk, improve revenue, and adhere to
legal requirements. This model helps you
identify policies allocated to business peo-
ple, which in turn allows management to
prepare for software implementation by
updating procedures, guidelines, training,
forms, and other assets needed to enforce
the policies. Some policies are also allocat-
59. ed to software for implementation.
Business Rules
Business rules are text statements that
decompose business policies. Business
rules describe what defines, constrains, or
enables the software behavior. You use
Business
Requirements
1
Why the project is being
undertaken.
Business
Requirements
User
Requirements
Software
Requirements
What users will be able to do
with the product.
What the developers
need to build.
Project
Charter
Product
Vision
63. Level 3:
Figure 2: User Requirements Model Roadmap
The Beginning
Good Practices for Developing User Requirements
March 2008 www.stsc.hill.af.mil 1 5
business rules to specify the controls that
govern user requirements and to clarify
which rules should be enforced in software
and which will be allocated to business
people. Because business rules require
data, defining the rules will uncover need-
ed data. User requirements depend on the
complete and correct enforcement of
business rules.
Class Model
A class model is a diagram that shows the
classes to be used in a system. A class is the
generic definition of a collection of simi-
lar objects (persons, places, events, and
physical artifacts). You use a class model
in projects employing object-oriented
software development methods, tools, or
databases.
Context Diagram
A context diagram is a model that shows
the system in its environment with the
external entities (people and systems) that
64. provide and receive information or mate-
rials to and from the system. This model
helps stakeholders to quickly and simply
define the project’s scope and to focus on
what the system needs as inputs and pro-
vides as outputs. A context diagram helps
the team derive requirements models
(such as actors, use cases, and data model
information) and can reveal possible
scope creep problems as new external
entities are added.
Data Dictionary
A data dictionary is a model that provides
a description of the data attributes and
structures used in a system. This model is
a central place for defining each data ele-
ment and describing its data type, length,
and format. Some project teams use data
modeling tools that provide data dictio-
nary capabilities.
Data Flow Diagram (DFD)
A DFD is a model that shows related
inputs, processes, and outputs for process-
es that respond to external or temporal
events. Unlike use cases (which are orient-
ed toward actor goals), DFDs focus on
the data that goes in and out of each
process, taking an internal view of how
the system handles events.
Data Model
A data model shows the informational
needs of a system by illustrating the logi-
cal structure of data independent of the
65. data design or data storage mechanism.
You use a data model to identify, summa-
rize, and formalize the data attributes and
structures needed to satisfy functional
requirements and to create an easy-to-
maintain database. Data models help to
simplify design and programming and
help identify external data entities (other
systems that supply data to the software).
Data Table
A data table is a model in the form of a
table that contains sample data to elicit
and validate a data model or data dictio-
nary. Each row represents a set of occur-
rences in an entity, and each column rep-
resents sample attributes.
Decision Table
A decision table is a model that specifies
complex business rules concisely in an
easy-to-read tabular format. A decision
table documents all the possible condi-
tions and actions that need to be account-
ed for in business rules. Conditions are fac-
tors, data attributes, or sets of attributes
and are equivalent to the left side of atom-
ic business rules. Actions are conclusions,
decisions, or tasks and are equivalent to
the right side of atomic business rules.
Factors that must be evaluated form the
top rows of the table. Actions make up
the bottom rows of the table.
Decision Tree
66. A graphical alternative to a decision table,
a decision tree presents conditions and
actions in sequence. Each condition is
graphed with a decision symbol represent-
ing yes or no (or a true or false conclusion).
Branches to additional conditions are
drawn left to right. Actions are drawn
inside rectangles to the right of the branch
to which they apply.
Dialog Hierarchy
A dialog hierarchy is a model that shows
the dialogs in a system (or Web page) as a
hierarchy. It does not show transitions.
Dialog Map
A dialog map is a diagram that illustrates
the architecture of a system’s user inter-
face. It shows the visual elements that
users manipulate to step through tasks
when interacting with the system. Dialog
maps can be used to uncover missing or
erroneous use case paths and to validate
use cases, scenarios, or both in require-
ments walkthroughs with users.
Event-Response Table
An event-response table model identifies
each event (an input stimulus that triggers
the system to carry out a function) and the
event responses resulting from those
functions. An event-response table defines
the conditions to which the system must
respond, thereby defining the functional
requirements at a scope level. (Each event
67. requires a predictable response from the
system.) This model can also reveal needs
for external database access or file feeds.
Glossary
The glossary is a list of definitions of busi-
ness terms and concepts relevant to the
software being developed or enhanced.
Persona
The persona is a description of an actor
as a fictitious system user or archetype.
You describe each persona as if he or she
is a real person with personality, family,
work background, preferences, behavior
patterns, and personal attitudes. The focus
is on behavior patterns rather than job
descriptions. Each persona description is
written as a narrative flow of the person’s
day with added details about personality.
Four or five personas represent the roles
that use the system most often or are
most important to the functional require-
ments.
Process Map
A process map is a diagram that shows the
sequence of steps, inputs, and outputs
needed to handle a business process
across multiple functions, organizations,
or job roles. This model helps you identi-
fy the processes that are allocated to the
business (manual processes) and those
that will be allocated to software.
Prototype
68. A prototype is a partial or preliminary ver-
sion of a system created to explore or val-
idate requirements. Exploratory proto-
types can be mock-ups using paper, white-
boards, or software tools.
Relationship Map
A relationship map is a diagram that
shows the information and products that
are exchanged among external customers,
suppliers, and key functions in the organi-
zation. This model helps you understand
the organizational context of the project
by identifying affected business functions
and their inputs and outputs.
Scenario
A scenario is a description of a specific
occurrence of a path through a use case
(i.e., a use case instance). Example: A cus-
tomer calls to reschedule a job, adding
another service and requesting a repeat
customer discount.
Stakeholder Categories
Stakeholder categories are structured
arrangements of groups or individuals
who have a vested interest in the product
being developed. You use this model to
understand who has an interest in or who
has influence on the product, who will use
the software and its outputs, and who the
product will affect in some way. These
69. groups and individuals will need to be
kept informed about requirements
progress, conflicts, changes, and priorities.
State-Data Matrix
A state-data matrix model shows attribut-
es that are added or changed during a state
change. Each attribute is identified in the
data model and data dictionary.
State Diagram
A state diagram is a visual representation
of the life cycle of a data entity. Events
trigger changes in data, resulting in a new
state for that entity. Each state is a defined
condition of an entity, a hardware compo-
nent, or the entire system that requires
data, rules, and actions. A state diagram
can also show actions that occur in
response to state changes. You use a state
diagram to understand how events affect
data and to identify missing requirements
such as events, business rules, data attrib-
utes, and use case steps.
Story
A story is a text description of a path
through a use case that users typically doc-
ument. Stories replace use cases and sce-
narios when you are planning releases for
agile projects. Stories are essentially
detailed scenarios, but each story is judged
by developers to require less than two
weeks to develop. When combined with
acceptance tests, stories are roughly equiv-
alent to use cases.
70. Use Case
The use case describes in abstract terms
how actors use the system to accomplish
goals. Each use case is a logical piece of
user functionality that can be initiated by an
actor and described from the actor’s point
of view in a technology-neutral manner.
Use cases summarize a set of related sce-
narios. The purpose of use cases is to
reveal functional requirements by clarifying
what users need to accomplish when inter-
acting with the system. Use cases are a nat-
ural way to organize functional require-
ments and can be easier for users to under-
stand and verify than textual functional
requirements statements.
Use Case Map
The use case map is a model that illus-
trates the work flow of use cases. Each
use case map represents a set of highly
cohesive use cases sharing the same data,
often triggered by the same events or ini-
tiated by the same actor.
Use Case Package
The use case package is a logical, cohesive
group of use cases that represents higher
level system functionality. You create a use
case package by combining use case maps
or grouping use cases. Most systems will
have multiple packages. You can use a
UML file folder notation to show each
package, and you can name each package
71. according to its functionality.
Good Practices for Modeling
User Requirements
Following good requirements modeling
practices (see Good Practices for Modeling
User Requirements, Table 1) is the key to
successful development of user require-
ments. These practices accelerate model-
ing, engage stakeholders, and give you
high-quality requirements – ones that are
correct, complete, clear, consistent, and
relevant.
The first good practice is to represent
and agree on the project’s scope early in
requirements elicitation. Why? It has to do
with scope creep – the unrestrained
expansion of requirements as the project
proceeds. Scope creep is one of the great-
est risks in software development [6]. A
clear definition of product scope narrows
the project’s focus to enable better plan-
ning, better use of time, and better use of
resources. Moreover, scope-level models
establish a common language that team
members can use to communicate about
the requirements and help to articulate the
boundary between what is in and what is
not in scope for the product.
Another good practice, as mentioned
earlier, is to document your product using
multiple user requirements models. Each
model describes one aspect of a problem
72. the product will address. Thus, no single
model can describe all the requirements.
Furthermore, elements of one model
often link to elements of another, so one
model can be used to uncover related or
missing elements in another model.
It is also good to use both text and
graphics to represent user needs. Multiple
representations tap into different modes
of human thinking. Some people think
more precisely with words, and others
understand concepts more quickly via dia-
grams. Using both types of representa-
tions leverages these different thinking
modes. In addition, mixing text and
graphics makes requirements develop-
ment more interesting and engaging. It
provides variety and permits stakeholders
to understand their requirements from
more than one angle.
You should also select models that fit
the domain of your product. That is
because some models are better suited to
communicate requirements for certain
domains. For example, When models (such
as an event-response table and a state
machine diagram) are well suited to
dynamic domains – those that respond to
continually changing events to store data
and act on it based on its state at a point.
Another well-known good practice is
to develop your requirements iteratively.
Each iteration is a self-contained mini-
73. project in which you undertake a set of
activities – elicitation, analysis, specifica-
tion, and validation – resulting in a subset
of requirements. The rationale for this
practice is that user requirements seldom
remain unchanged for a long period. On
teams using agile methods, each iteration
also incorporates the work needed to
deliver the working software that satisfies
those requirements. In some domains,
requirements change faster than the sys-
tem or subsystem can be developed. In
addition, the cost of implementing
changes increases dramatically as the pro-
ject proceeds. Developing requirements in
an evolving manner is essential in reducing
these risks.
You can also use requirements models
to identify requirements defects. The
interconnections among the models help
to expose any inconsistencies in related
models. This self-checking accelerates the
team’s ability to uncover missing, erro-
neous, vague, or conflicting requirements.
The Beginning
1 6 CROSSTALK The Journal of Defense Software Engineering
March 2008
1. Define, represent, and agree on the project’s scope early in
requirements
elicitation.
2. Document your product using multiple user requirements
74. models.
3. Select models that fit the domain of your system.
4. Develop requirements models iteratively.
5. Use requirements models to identify requirements defects.
6. Use models to communicate: Create simple, readable
diagrams focused less
on beauty and more on understanding.
7. Conduct retrospectives as you iterate through requirements
development.
Table 1: Summary: Good Practices for Modeling User
Requirements
Good Practices for Developing User Requirements
March 2008 www.stsc.hill.af.mil 1 7
When you are creating graphical mod-
els, it is crucial to create simple, readable
diagrams. The benefit of diagrams is that
they give you a way to quickly communi-
cate complex, controversial, or unclear
requirements. Thus, you should avoid
complex, hard-to-read diagrams. Draw
diagrams manually to begin with or use an
easy-to-learn drawing tool. Keep them
simple and easy to read. Focus on main-
taining accuracy and exposing unclear or
incorrect requirements – not beauty or
completeness.
The final good practice I want to men-
tion applies whether or not you are using
75. modeling: I always tell my clients to con-
duct short retrospectives at the end of
each requirements iteration. A retrospective
is a special meeting in which the team
explores what works, what does not work,
what can be learned from the just com-
pleted iteration, and what ways to adapt
their processes and techniques before
starting another iteration [10, 11].
Retrospectives allow for early learning and
correction and may be your team’s most
powerful tool for process improvement.
On Your Way
Software development teams enjoy access
to a world of tools and technologies, but
building truly successful software still
depends on team members gaining a deep
understanding of user needs. When your
team is developing a software product,
you will save time, money, and frustration
by using appropriate models to describe
and analyze the product’s user require-
ments.u
References
1. Reifer, Donald J. “Profiles of Level 5
CMMI Organizations.” CrossTalk
Jan. 2007.
2. Schwaber, Carey. “The Root of the
Problem: Poor Requirements.” IT
View Research Document. Forrester
Research, 2006
76. 3. Dabney, James B., and Gary Barber.
“Direct Return on Investment of
Software Independent Verification and
Validation: Methodology and Initial
Case Studies.” Assurance Technology
Symposium, June 2003 <http://
sarpresults.ivv.nasa.gov/ViewResearch
/24.jsp>.
4. Hooks, Ivy F., and Kristina A. Farry.
Customer-Centered Products: Creat-
ing Successful Products Through
Smart Requirements Management.
New York: Amacom, 2001.
5. Nelson, Mike, James Clark, and
Martha Ann Spurlock. “Curing the
Software Requirements and Cost
Estimating Blues.” The Defense
Acquisition University Program
Manager Magazine Nov.-Dec. 1999.
6. Jones, Capers. Patterns of Software
Systems Failure and Success. Boston,
MA: Thomson Computer Press, 1996.
7. Gottesdiener, Ellen. Software
Requirements Memory Jogger: A
Pocket Guide to Help Software and
Business Teams Develop and Manage
Requirements. Methuen, MA:
Goal/QPC, 2005.
8. Institute of Electrical & Electronics
Engineers (IEEE). “IEEE Software
77. Engineering Body of Knowledge.”
IEEE Computer Society, 2004
<www.swebok.org>.
9. Standish Group International.
“CHAOS Chronicles.” Standish
Group International, 2003.
10. Kerth, Norman L. “Project Retro-
spectives: A Handbook for Team
Reviews.” New York: Dorset House,
2001.
11. Gottesdiener, Ellen. “Team Retro-
spectives for Better Iteration Assess-
ment.” The Rational Edge Apr. 2003
<http://ebgconsulting.com/Pubs/
Articles/TeamRetrospectives-Gottes
diener.pdf>.
About the Author
Ellen Gottesdiener,
principal consultant, EBG
Consulting, helps get the
right requirements so
projects start smart and
deliver the right product
at the right time. Her book, “Require-
ments by Collaboration: Workshops for
Defining Needs” describes how to use
multiple models to elicit requirements in
collaborative workshops, and “The
Software Requirements Memory Jogger”
describes essentials for requirements
78. development and management. In addi-
tion to providing training, eLearning and
consulting services, she speaks at and
advises for industry conferences, writes
articles, and serves on the Expert Review
Board of the International Institute of
Business Analysis Business Analysis
Body of Knowledge.
EBG Consulting, Inc.
1424 Ironwood DR West
Carmel, IN 46033
Phone: (317) 844-3747
E-mail: [email protected]
Get Your Free Subscription
Fill out and send us this form.
517 SMXS/MXDEA
6022 Fir Ave
Bldg 1238
Hill AFB, UT 84056-5820
Fax: (801) 777-8069 DSN: 777-8069
Phone: (801) 775-5555 DSN: 775-5555
Or request online at www.stsc.hill.af.mil
NAME:______________________________________________
__________________________
RANK/GRADE:_______________________________________