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

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, 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

2) How have the methods for systems development evolved?

Ans: Different types of system development methodologies are used in designing information
system. Depending upon the actual requirement of the system, different approaches for data processing are adopted. However, some system groups recommend the Centralised data processing system while others may go in for distributed data processing system. In a Centralised data processing, one or more centralized computers are used for processing and the retrieval of information is done from them. The distributed processing systems involve number of computers located remotely in the branches/departments of the organisation. The client/server technologies are also gaining popularity these days. 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.

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. 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 specification: An information management project is concerned with getting the right information, in the right hands, at the right time to make the right decision. Information systems analysis and requirements analysis produces a requirements specification. This specification states the project goal and the related data storage, data movement, security, quality, usage, functional and non-functional requirements that must be achieved in order to achieve the business goal stated in the business case. It is intended to act as the master list (roadmap) of all requirements that must be met by the project. systems analysis: Information management projects are similar--Requirements should be identified first, and approved by the business owner, before technical design begins. This way, the business owner is involved in signoff of the requirements. The technical team is also involved with specifying requirements so they are in a better position to understand what is needed. requirements analysis Requirements analysis activities include:

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

4) How is the feasibility of a project assessed?

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

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 Leaders 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.

o o

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.

6) What is the role of different types of Unified Modeling Language diagrams?

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.

Types of UML Diagrams

UML defines nine types of diagrams: class (package), object, use case, sequence, collaboration, statechart, activity, component, and deployment.

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

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

a user uses a system, not how the system operates internally.

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.

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, 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.