Escolar Documentos
Profissional Documentos
Cultura Documentos
that describes the stages involved in an information system development project, from an initial feasibility study through maintenance of the completed application. The System Development Life Cycle framework provides a sequence of activities for system designers and developers to follow. It consists of a set of steps or phases in which each phase of the SDLC uses the results of the previous one. A Systems Development Life Cycle (SDLC) adheres to important phases that are essential for developers, such as planning, analysis, design, and implementation, and are explained in the section below. A number of system development life cycle (SDLC) models have been created: waterfall, fountain, spiral, build and fix, rapid prototyping, incremental, and synchronize and stabilize. The oldest of these, and the best known, is the waterfall model: a sequence of stages in which the output of each stage becomes the input for the next. These stages can be characterized and divided up in different ways, including the following:
Project planning, feasibility study: Establishes a high-level view of the intended project and determines its goals.
Systems analysis, requirements definition: Defines project goals into defined functions and operation of the intended application. Analyzes end-user information needs.
Systems design: Describes desired features and operations in detail, including screen layouts, business rules, process diagrams, pseudocode and other documentation.
Implementation: The real code is written here. Integration and testing: Brings all the pieces together into a special testing environment, then checks for errors, bugs and interoperability.
Acceptance, installation, deployment: The final stage of initial development, where the software is put into production and runs actual business.
Maintenance: What happens during the rest of the software's life: changes, correction, additions, : moves to a different computing platform and more. This, the least glamorous and perhaps most important step of all, goes on seemingly forever. oes
Analysis of business requirements and business models; Business analysis requirements and business requirements analysis; Requirements analysis and definition of data warehouse requirements; and Systems analysis requirements modeling.
Who is involved with requirements analysis? A requirements specification team should be comprised of:
Business owner, to provide input to all specifications; Data steward, to provide input on data quality and data security; Data modeler, to analyze data requirements and take ownership for the requirements specification; Data analyst to analyze and document data movement requirements; and Business intelligence analyst, to analyze and document information usage requirements. Projects cannot succeed without common understanding of requirements
5) What are the roles of team members, and what skills do they need? Ans: Roles of Team Leader
Works with leadership on goals and expectations. Negotiates with leadership to gain high level commitment for necessary team resources. Establishes goals, objectives and target deadlines for team. Establishes and gains consensus on team ground rules. Encourages fair play with team rules and ensures all team members are held accountable for their actions.
Communicates expectations of the team and the importance of completing team assignments on time.
Ensures team establishes and monitors goals. Takes proactive steps in eliminating team members who do not adhere to team rules. Helps the team with conflict resolution and educates them on how to constructively solve their problems.
Reviews and monitors team progress toward goals. Ensures team celebrates successes.
Team development
o o
The ability to instruct and educate team members on team dynamics The ability to see the big picture and keep the team focused Conflict resolution skills Reinforcement of team ground rules
Has the ability to negotiate with senior leadership to ensure the team has the necessary resources (time, people, budget) needed to accomplish their goals. Is comfortable providing feedback to the team as well as individual team members. This is important because appropriate feedback helps to resolve conflict and problem resolution. It also helps to build trust amongst team members.
Has a good understanding of team dynamics and understands that conflict can be a healthy team dynamic if managed properly.
Ans: UML stands for Unified Modeling Language. This object-oriented system of notation has
evolved from the work of Grady Booch, James Rumbaugh, Ivar Jacobson, and the Rational Software Corporation. These renowned computer scientists fused their respective technologies into a single, standardized model. Today, UML is accepted by the Object Management Group (OMG) as the standard for modeling object oriented programs.
Class Diagrams
Class diagrams are the backbone of almost every object oriented method, including UML. They describe the static structure of a system. A class diagram is a UML structural diagram. Depending on the complexity of a system, we can use a single class diagram to model the entire system, or we can use several class diagrams to model the components of the system.
Class diagrams are the blueprints of your system. Use class diagrams to model the objects that make up the system, to display the relationships between the objects, and to describe what those objects do.
Library Domain Model describes main classes and relationships which could be used during analysis phase to better understand domain area for Integrated Library System (ILS), also known as a Library Management System (LMS).
Package Diagrams
Package diagrams are a subset of class diagrams, but developers sometimes treat them as a separate technique. Package diagrams organize elements of a system into related groups to minimize dependencies between packages.
Object Diagrams
Object diagrams describe the static structure of a system at a particular time. They can be used to test class diagrams for accuracy.
Use case diagrams model the functionality of system using actors and use cases. A use case diagram is a UML behavioral diagram that focuses on the requirements and describes the highlevel functions and scope of a system. These diagrams identify the users and show interactions between the system and the user. Use case diagrams can depict an entire system or only significant portions of the system. The use cases and actors in use case diagrams describe how
Sequence Diagrams
Sequence diagrams describe interactions among classes in terms of an exchange of messages over terms time. A sequence diagram is a UML structural diagram that provides a view of the
chronological sequence of messages between objects or classifier roles that work together in an interaction or interaction instance. A sequence diagram consists of a group of sequence instances, which are represented by lifelines, and the messages that they exchange during the interaction.
Collaboration Diagrams
Collaboration diagrams represent interactions between objects as a series of sequenced messages. Collaboration diagrams describe both the static structure and the dynamic behavior of a system.
Statechart Diagrams
Statechart diagrams describe the dynamic behavior of a system in response to external stimuli. Statechart diagrams are especially useful in modeling reactive objects whose states are triggered by specific events.
Activity Diagrams
Activity diagrams illustrate the dynamic nature of a system by modeling the flow of control from activity to activity. An activity represents an operation on some class in the system that results in a change in the state of the system. Typically, activity diagrams are used to model workflow or business processes and internal operation.
Component Diagrams
Component diagrams describe the organization of physical software components, including source code, run-time (binary) code, and executables. time
Deployment Diagrams
Deployment diagrams depict the physical resources in a system, including nodes, components, and connections.
Ans: The Unified Process divides the project into four phases:
Inception Phase
Inception is the smallest phase in the project, and ideally it should be quite short. If the Inception Phase is long then it may be an indication of excessive up-front specification, which is contrary to the spirit of the Unified Process. The following are typical goals for the Inception phase.
Establish a justification or business case for the project Establish the project scope and boundary conditions Outline the use cases and key requirements that will drive the design tradeoffs Outline one or more candidate architectures Identify risks Prepare a preliminary project schedule and cost estimate
The Lifecycle Objective Milestone marks the end of the Inception phase.
Elaboration Phase
During the Elaboration phase the project team is expected to capture a healthy majority of the system requirements. However, the primary goals of Elaboration are to address known risk factors and to establish and validate the system architecture. Common processes undertaken in this phase include the creation of use case diagrams, conceptual diagrams (class diagrams with only basic notation) and package diagrams (architectural diagrams).
The architecture is validated primarily through the implementation of an Executable Architecture Baseline. This is a partial implementation of the system which includes the core, most architecturally significant, components. It is built in a series of small, timeboxed iterations. By the end of the Elaboration phase the system architecture must have stabilized and the executable architecture baseline must demonstrate that the architecture will support the key system functionality and exhibit the right behavior in terms of performance, scalability and cost. The final Elaboration phase deliverable is a plan (including cost and schedule estimates) for the Construction phase. At this point the plan should be accurate and credible, since it should be based on the Elaboration phase experience and since significant risk factors should have been addressed during the Elaboration phase.
Construction Phase
Construction is the largest phase in the project. In this phase the remainder of the system is built on the foundation laid in Elaboration. System features are implemented in a series of short, timeboxed iterations. Each iteration results in an executable release of the software. It is customary to write full text use cases during the construction phase and each one becomes the start of a new iteration. Common UML (Unified Modelling Language) diagrams used during this phase include Activity, Sequence, Collaboration, State (Transition) and Interaction Overview diagrams.
Transition Phase
The final project phase is Transition. In this phase the system is deployed to the target users. Feedback received from an initial release (or initial releases) may result in further refinements to be incorporated over the course of several Transition phase iterations. The Transition phase also includes system conversions and user training.