P. 1


|Views: 2|Likes:
Published by Anuradhait

More info:

Published by: Anuradhait on Aug 09, 2011
Copyright:Attribution Non-commercial


Read on Scribd mobile: iPhone, iPad and Android.
download as PDF, TXT or read online from Scribd
See more
See less





Institute of Information Technology (IIT) Jahangirnagar University Savar, Dhaka-1342

Lab Report on Information system Analysis and Design Lab
Lab Report No Course Name Course Code Submitted To Submitted By Class Roll :01 : Information system Analysis and Design Lab : IT-404 : Jesmin Akhter, Lecturer, Institute of Information Technology : Cluster -1 (First 10 students) : 1398 To 1408

bugs and interoperability. then checks for errors. fountain. It consists of a set of steps or phases in which each phase of the SDLC uses the results of the previous one. Integration and testing: Brings all the pieces together into a special testing environment. requirements definition: Defines project goals into defined functions and operation of the intended application. rapid prototyping. and are explained in the section below. pseudocode and other documentation. from an initial feasibility study through maintenance of the completed application. and implementation. incremental. The System Development Life Cycle framework provides a sequence of activities for system designers and developers to follow. Analyzes end-user information needs.1) What is the Systems Development Life Cycle? Ans: The systems development life cycle (SDLC) is a conceptual model used in project management that describes the stages involved in an information system development project. such as planning. feasibility study: Establishes a high-level view of the intended project and determines its goals. business rules. is the waterfall model: a sequence of stages in which the output of each stage becomes the input for the next. and synchronize and stabilize. and the best known. The oldest of these. A number of system development life cycle (SDLC) models have been created: waterfall. including the following:  Project planning. .  Acceptance. process diagrams. including screen layouts. deployment: The final stage of initial development. spiral. analysis. A Systems Development Life Cycle (SDLC) adheres to important phases that are essential for developers. These stages can be characterized and divided up in different ways. build and fix.   Implementation: The real code is written here.  Systems analysis. installation. where the software is put into production and runs actual business.  Systems design: Describes desired features and operations in detail. design.

This. goes on seemingly forever. additions. correction. the least glamorous and perhaps most important step of all. Maintenance: What happens during the rest of the software's life: changes. : moves to a different computing platform and more. oes .

Depending upon the actual requirement of the system. one or more centralized computers are used for processing and the retrieval of information is done from them. In a Centralised data processing. Systems development methodologies have evolved from technical approaches through to a people/organisational focus and more recently an increased emphasis on Business Process Reengineering (BPR) has been witnessed. The client/server technologies are also gaining popularity these days. The distributed processing systems involve number of computers located remotely in the branches/departments of the organisation. different approaches for data processing are adopted.2) How have the methods for systems development evolved? Ans: Different types of system development methodologies are used in designing information system. . However. some system groups recommend the Centralised data processing system while others may go in for distributed data processing system.

at the right time to make the right decision. . usage. data movement. requirements analysis Requirements analysis activities include:     Analysis of business requirements and business models. It helps ensure that the technical team does not design and build something that is not specified. Requirements management will ensure that project management scope for design and construction does not deviate from requirements thus minimizing time delays and cost over-run due to re-work. Requirements analysis and definition of data warehouse requirements. This specification states the project goal and the related data storage. in the right hands. The technical team is also involved with specifying requirements so they are in a better position to understand what is needed.3) How is a project initiated? Ans: The requirements specification provides a means of specifying all requirements and the criteria that will be used to accept that the requirements have been met. systems analysis: Information management projects are similar--Requirements should be identified first. This way. security. before technical design begins. Business analysis requirements and business requirements analysis. and Systems analysis requirements modeling. requirements specification: An information management project is concerned with getting the right information. functional and non-functional requirements that must be achieved in order to achieve the business goal stated in the business case. and approved by the business owner. Information systems analysis and requirements analysis produces a requirements specification. It is intended to act as the master list (roadmap) of all requirements that must be met by the project. quality. the business owner is involved in “signoff” of the requirements.

to provide input on data quality and data security. Data steward. to analyze data requirements and take ownership for the requirements specification. to analyze and document information usage requirements. and Business intelligence analyst. to provide input to all specifications. Data modeler.Who is involved with requirements analysis? A requirements specification team should be comprised of:    Business owner. “Projects cannot succeed without common understanding of requirements”   . Data analyst to analyze and document data movement requirements.

A wise person once said.” . feasibility is the measure of how beneficial the development or enhancement of an information system would be to the business. but not all things are profitable. Information systems development projects are usually subjected to one or more feasibility analyses prior to and during their life.4) How is the feasibility of a project assessed? Ans: A major but optional activity within systems analysis is feasibility analysis. In the article “The surplus value of the existent. the definitions of the terms feasibility and feasibility studies in theory concerning construction are not necessarily directly applicable. which are asked. Implementing this in the context of sustainable urban restructuring. Most of the time. Project feasibility can be defined as the overall feasibility of a production project. "All things are possible. we come to the following definition of project feasibility: “The ability to execute urban restructuring projects. which is insufficient for a project to “be able of being accomplished” In the context of project management. this quote addresses feasibility. the terms possible and practicable are not directly mentioned. Project feasibility assessment distinction itself (in practice) of feasibility assessment by the questions. Systems analysts are often called upon to assist with feasibility analysis for proposed systems development projects. with all available tools and with the support among the most important participants. Compared to the above-described definitions of Castle and Gruenberg & Weight we can conclude that this definition does not cover the whole by only mentioning the weighing component." Simply stated. Feasibility analysis is the process by which feasibility is measured. In an information systems development project context. the terms practicable and possible are more related to the term project feasibility. In literature in which feasibility concerning urban restructuring or feasibility concerning strategic spatial policy appears. In practice however. the author reduces the purpose of feasibility studies in the context of urban regeneration to “the weighing of qualities and costs” . the terms costs and means on one hand and qualities and objectives on the other are related to feasibility.” for example.

people. Establishes goals.   Reviews and monitors team progress toward goals. .    Ensures team establishes and monitors goals. It also helps to build trust amongst team members. Encourages fair play with team rules and ensures all team members are held accountable for their actions. Helps the team with conflict resolution and educates them on how to constructively solve their problems. Takes proactive steps in eliminating team members who do not adhere to team rules. Team Leader’s Skills  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  Coaching team members on appropriate team behaviors. objectives and target deadlines for team. o o  Has the ability to negotiate with senior leadership to ensure the team has the necessary resources (time. Establishes and gains consensus on team ground rules. and what skills do they need? Ans: Roles of Team Leader      Works with leadership on goals and expectations.5) What are the roles of team members. This is important because appropriate feedback helps to resolve conflict and problem resolution.   Has a good understanding of team dynamics and understands that conflict can be a healthy team dynamic if managed properly. Negotiates with leadership to gain high level commitment for necessary team resources. Is comfortable providing feedback to the team as well as individual team members. budget) needed to accomplish their goals. Ensures team celebrates successes.  Communicates expectations of the team and the importance of completing team assignments on time.

component.  Class diagrams are the blueprints of your system. standardized model. use case. James Rumbaugh. collaboration. object. sequence. Ivar Jacobson. Today. UML is accepted by the Object Management Group (OMG) as the standard for modeling object oriented programs. statechart. or we can use several class diagrams to model the components of the system. . and to describe what those objects do. Class Diagrams  Class diagrams are the backbone of almost every object oriented method. Use class diagrams to model the objects that make up the system. activity.6) What is the role of different types of Unified Modeling Language diagrams? Ans: UML stands for Unified Modeling Language. and the Rational Software Corporation. Depending on the complexity of a system. including UML. These renowned computer scientists fused their respective technologies into a single. to display the relationships between the objects. This object-oriented system of notation has evolved from the work of Grady Booch. and deployment. we can use a single class diagram to model the entire system. A class diagram is a UML structural diagram. They describe the static structure of a system. Types of UML Diagrams UML defines nine types of diagrams: class (package).

but developers sometimes treat them as a separate technique. Package diagrams organize elements of a system into related groups to minimize dependencies between packages. . Package Diagrams  Package diagrams are a subset of class diagrams. also known as a Library Management System (LMS).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).

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. Use Case Diagrams  Use case diagrams model the functionality of system using actors and use cases. They can be used to test class diagrams for accuracy. The use cases and actors in use case diagrams describe how .Object Diagrams  Object diagrams describe the static structure of a system at a particular time. A use case diagram is a UML behavioral diagram that focuses on the requirements and describes the highlevel functions and scope of a system.

Sequence Diagrams  Sequence diagrams describe interactions among classes in terms of an exchange of messages over terms time.a user uses a system. not how the system operates internally. 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. and the messages that they exchange during the interaction. A sequence diagram consists of a group of sequence instances. . which are represented by lifelines.

.Collaboration Diagrams  Collaboration diagrams represent interactions between objects as a series of sequenced messages. Statechart Diagrams  Statechart diagrams describe the dynamic behavior of a system in response to external stimuli. Collaboration diagrams describe both the static structure and the dynamic behavior of a system. Statechart diagrams are especially useful in modeling reactive objects whose states are triggered by specific events.

An activity represents an operation on some class in the system that results in a change in the state of the system. and executables. activity diagrams are used to model workflow or business processes and internal operation. Component Diagrams  Component diagrams describe the organization of physical software components. Typically. time . including source code. run-time (binary) code.Activity Diagrams  Activity diagrams illustrate the dynamic nature of a system by modeling the flow of control from activity to activity.

including nodes. components. .Deployment Diagrams  Deployment diagrams depict the physical resources in a system. and connections.

conceptual diagrams (class diagrams with only basic notation) and package diagrams (architectural diagrams).       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. the primary goals of Elaboration are to address known risk factors and to establish and validate the system architecture. 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. Elaboration Phase During the Elaboration phase the project team is expected to capture a healthy majority of the system requirements. However. . Common processes undertaken in this phase include the creation of use case diagrams. The following are typical goals for the Inception phase. and ideally it should be quite short.7) What is the Unified Process and what are its phases? Ans: The Unified Process divides the project into four phases:     Inception Elaboration Construction Transition Inception Phase Inception is the smallest phase in the project.

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. 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. Construction Phase Construction is the largest phase in the project. This is a partial implementation of the system which includes the core. most architecturally significant. scalability and cost. . System features are implemented in a series of short. It is built in a series of small. At this point the plan should be accurate and credible. Collaboration. components.The architecture is validated primarily through the implementation of an Executable Architecture Baseline. timeboxed iterations. State (Transition) and Interaction Overview diagrams. Transition Phase The final project phase is Transition. The final Elaboration phase deliverable is a plan (including cost and schedule estimates) for the Construction phase. In this phase the remainder of the system is built on the foundation laid in Elaboration. since it should be based on the Elaboration phase experience and since significant risk factors should have been addressed during the Elaboration phase. In this phase the system is deployed to the target users. Each iteration results in an executable release of the software. The Transition phase also includes system conversions and user training. Sequence. 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.

You're Reading a Free Preview

/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->